Japin Li <japinli@hotmail.com> writes:
> On Mon, 12 Jul 2021 at 23:30, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I do not think this is a bug at all. The behavior is, and always has
>> been, that we report stats when we are about to wait for client input
>> and are not inside a transaction. Likewise for NOTIFY. The proposed
>> patch randomly changes that in a way that is very likely to break
>> clients.
> Sorry, I'm not very clearly why we can not process NOTIFY when a transaction is
> end.
The protocol contract for that is that NOTIFY is delivered *between*
transactions. With the proposed patch, the notification can be delivered
in the middle of the new transaction created by COMMIT AND CHAIN. This
creates semantic issues --- in particular, if that second transaction is
later rolled back, does that mean we should re-send the notification?
The NOTIFY man page describes this explicitly:
... Secondly, if a listening session receives a notification signal
while it is within a transaction, the notification event will not be
delivered to its connected client until just after the transaction is
completed (either committed or aborted). Again, the reasoning is that
if a notification were delivered within a transaction that was later
aborted, one would want the notification to be undone somehow — but
the server cannot “take back” a notification once it has sent it to
the client. So notification events are only delivered between
transactions.
(protocol.sgml is a bit wishy-washy about this point, but I think we
should lock the wording there down harder. We have never delivered
notifies intra-transaction, and now is no time to start.)
regards, tom lane
