Re: Statistics updates is delayed when using `commit and chain`

On Tue, Jul 13, 2021 at 8:18 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Japin Li <japinli(at)hotmail(dot)com> writes:
> > On Mon, 12 Jul 2021 at 23:30, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

David J.