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

From: Lætitia Avrot <laetitia(dot)avrot(at)gmail(dot)com>
To: Japin Li <japinli(at)hotmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Statistics updates is delayed when using `commit and chain`
Date: 2021-07-26 15:53:34
Message-ID: CAB_COdjhzA+9URWOekr3s=J-+kMsUQDcjae2rF00Z5X-jDKzuA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Dear all,

Le mer. 14 juil. 2021 à 08:54, Japin Li <japinli(at)hotmail(dot)com> a écrit :

>
> On Wed, 14 Jul 2021 at 12:06, David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> > On Tue, Jul 13, 2021 at 9:02 PM David G. Johnston <
> > david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> >
> >> We are already doing that now, though I argue we are in fact documenting
> >> the "other clients receive the notification as soon as committed -
> >> regardless of chaining" situation (the additional restrictions on
> receiving
> >> are then what cause the chain authoring client to wait).
> >>
> >>
> > Specifically:
> >
> > Firstly, if a NOTIFY is executed inside a transaction, the notify events
> > are not delivered until and unless the transaction is committed.
> >
> > vs.
> >
> > So notification events are only delivered between transactions.
> >
> > I'll accept that "and-chain" means there is no "between transactions"
> > period. But there is no qualification to "until the transaction is
> > committed".
> >
>
> There are two cases:
>
> 1. Should we update the statistics when "and-chain" ends?
> 2. Should we deliver the notification when "and-chain" ends?
>
> For the first one, I think we should update the statistics when
> "and-chain" ends
> because it makes statistics more accurate. For the second one, maybe I
> misunderstand
> the "and-chain", tested it aggin and find the notifications will not
> deliver if
> the last transaction is aborted.
>
> --
> Regrads,
> Japin Li.
> ChengDu WenWu Information Technology Co.,Ltd.
>
>
It seems to me that the important question is : are chained transactions
normal transactions?
If the answer is "yes", then we need to update the statistics and notify
before creating a new transaction because we need to completely end the
previous transaction before starting a new one with the same
characteristics.
If the answer is "no", then we contradict the SQL standard which states
there's nothing special with a transaction created by `and chain`:

>If <commit statement> contains AND CHAIN, then an SQL-transaction is
initiated. Any branch transactions of
> the SQL-transaction are initiated with the same transaction access mode,
transaction isolation level, and
> condition area limit as the corresponding branch of the SQL-transaction
just termi- nated.

and

> If <rollback statement> contains AND CHAIN, then an SQL-transaction is
initiated. Any branch transactions of
> the SQL-transaction are initiated with the same transaction access mode,
transaction isolation level, and
> condition area limit as the corresponding branch of the SQL-transaction
just terminated.

Have a nice day,

Lætitia

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alexander Lakhin 2021-07-26 20:00:00 Re: BUG #17116: Assert failed in SerialSetActiveSerXmin() on commit of parallelized serializable transaction
Previous Message Christoph Berg 2021-07-26 15:16:33 Re: BUG #17123: ALTER TABLE ... NO INHERIT leaves orphaned statistics behind