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

Поиск
Список
Период
Сортировка
От Lætitia Avrot
Тема Re: Statistics updates is delayed when using `commit and chain`
Дата
Msg-id CAB_COdjhzA+9URWOekr3s=J-+kMsUQDcjae2rF00Z5X-jDKzuA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Statistics updates is delayed when using `commit and chain`  (Japin Li <japinli@hotmail.com>)
Ответы Re: Statistics updates is delayed when using `commit and chain`  (Japin Li <japinli@hotmail.com>)
Список pgsql-bugs
Dear all,

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

On Wed, 14 Jul 2021 at 12:06, David G. Johnston <david.g.johnston@gmail.com> wrote:
> On Tue, Jul 13, 2021 at 9:02 PM David G. Johnston <
> david.g.johnston@gmail.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
 

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Christoph Berg
Дата:
Сообщение: Re: BUG #17123: ALTER TABLE ... NO INHERIT leaves orphaned statistics behind
Следующее
От: Alexander Lakhin
Дата:
Сообщение: Re: BUG #17116: Assert failed in SerialSetActiveSerXmin() on commit of parallelized serializable transaction