Horton

Re: LISTEN/NOTIFY testing woes

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Dilger <hornschnorter@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org, Martijn van Oosterhout <kleptog@gmail.com>
Date: 2019-11-24T18:39:15Z
Lists: pgsql-hackers 
Mark Dilger <hornschnorter@gmail.com> writes:
> On 11/23/19 8:50 PM, Mark Dilger wrote:
>> I have finished reading and applying your three patches and have moved 
>> on to testing them.  I hope to finish the review soon.

> After applying all three patches, the stress test that originally
> uncovered the assert in predicate.c no longer triggers any asserts.
> `check-world` passes.  The code and comments look good.

Thanks for reviewing!

After sleeping on it, I'm not really happy with what I did in
PrepareTransaction (that is, invent a separate PrePrepare_Notify
function).  The idea was to keep that looking parallel to what
CommitTransaction does, and preserve infrastructure against the
day that somebody gets motivated to allow LISTEN or NOTIFY in
a prepared transaction.  But on second thought, what would surely
happen when that feature gets added is just that AtPrepare_Notify
would serialize the pending LISTEN/NOTIFY actions into the 2PC
state file.  There wouldn't be any need for PrePrepare_Notify,
so there's no point in introducing that.  I'll just move the
comment saying that nothing has to happen at that point for NOTIFY.

			regards, tom lane

Commits

  1. Avoid assertion failure with LISTEN in a serializable transaction.

  2. Stabilize NOTIFY behavior by transmitting notifies before ReadyForQuery.

  3. Stabilize the results of pg_notification_queue_usage().