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.
This statement I believe is saying: "Why can we not SEND a notification when the first transactions ends and before the second transaction starts."
The protocol contract for that is that NOTIFY is delivered *between* transactions.
This is saying "We must not RECEIVE a notification unless the client is prepared to handle it - idle and not within a transaction."
In an example where a client is listening for its own notifications a notification sent in the first transaction would not be received by itself until after the second transaction completes (regardless of whether it committed or was rolled back). But since the first transaction committed its notification can never be undone and so there is no harm from releasing the notification as soon as the first transaction commits (or, at least none of the documented harms).
So, the choice to delay releasing the notification upon committing the first transaction of a chain is a design choice. Users using commit-and-chain are assumed to want all of their notifications in the chain to be sent as a single group (though we must not deduplicate notifications created in different parts of the chain). This, however, I do not believe is documented, nor is it the only valid choice, though it is what we do today without providing the user a choice.
