pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Japin Li <japinli@hotmail.com>
Cc: John Naylor <john.naylor@enterprisedb.com>
Cc: Lætitia Avrot <laetitia.avrot@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Statistics updates is delayed when using `commit and chain`
Date: Tue, 13 Jul 2021 23:18:40 -0400
Message-ID: <3453636.1626232720@sss.pgh.pa.us> (raw)
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>

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





view thread (29+ messages)  latest in thread

Message-ID: <3453636.1626232720@sss.pgh.pa.us>
Permalink:  ../3453636.1626232720@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/3453636.1626232720@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, japinli@hotmail.com, john.naylor@enterprisedb.com, laetitia.avrot@gmail.com, pgsql-bugs@lists.postgresql.org
  Subject: Re: Statistics updates is delayed when using `commit and chain`
  In-Reply-To: <3453636.1626232720@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox