From: Tom Lane <tgl@sss.pgh.pa.us>
To: Japin Li <japinli@hotmail.com>
cc: John Naylor <john.naylor@enterprisedb.com>,
        =?utf-8?Q?L=C3=A6titia?= Avrot <laetitia.avrot@gmail.com>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: Statistics updates is delayed when using `commit and chain`
In-reply-to: 
 <MEYP282MB1669840B952A11A638AEAA67B6139@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM>
References: 
 <CAB_COditjdhpZ4j=mZ3YG-uG=bqNtXWcBSAkwEJu3cX1X5myOA@mail.gmail.com>
 <MEYP282MB166920830D2969428D7028EBB6189@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM>
 <MEYP282MB1669EDFA7400DF3671400D27B6189@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM>
 <CAFBsxsHPm+CvjKGM+Whmxx0UWTCk8-meU44YcB9ya2xbw1+0Kw@mail.gmail.com>
 <MEYP282MB16691D91C25CB36079C9AC19B6179@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM>
 <CAB_COdjsWH+tjJHa4=FyUeSs+nCGegofiJwFmKzX+=xsGsP_Bw@mail.gmail.com>
 <MEYP282MB1669494707E6A49C2AC763FEB6159@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM>
 <CAFBsxsGbUgeGke_xEWfrnWqoL2U1LDCA2O5bMRr-0m8UxPqyxA@mail.gmail.com>
 <2950681.1626103840@sss.pgh.pa.us>
 <MEYP282MB1669840B952A11A638AEAA67B6139@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM>
Comments: In-reply-to Japin Li <japinli@hotmail.com>
	message dated "Wed, 14 Jul 2021 09:55:42 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <3453635.1626232720.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 13 Jul 2021 23:18:40 -0400
Message-ID: <3453636.1626232720@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3453636.1626232720%40sss.pgh.pa.us>
Precedence: bulk

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 transac=
tion 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 =E2=80=94=
 but
    the server cannot =E2=80=9Ctake back=E2=80=9D a notification once it h=
as 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