From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Dilger <hornschnorter(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Martijn van Oosterhout <kleptog(at)gmail(dot)com> |
Subject: | Re: LISTEN/NOTIFY testing woes |
Date: | 2019-11-24 18:39:15 |
Message-ID: | 11720.1574620755@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark Dilger <hornschnorter(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2019-11-24 19:01:04 | Re: LISTEN/NOTIFY testing woes |
Previous Message | Mark Dilger | 2019-11-24 18:25:57 | Re: LISTEN/NOTIFY testing woes |