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

Поиск
Список
Период
Сортировка
От Japin Li
Тема Re: Statistics updates is delayed when using `commit and chain`
Дата
Msg-id MEYP282MB16691A6E80DF769F04BF9EB0B6E99@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
обсуждение исходный текст
Ответ на Re: Statistics updates is delayed when using `commit and chain`  (Lætitia Avrot <laetitia.avrot@gmail.com>)
Ответы Re: Statistics updates is delayed when using `commit and chain`  (Laetitia Avrot <laetitia.avrot@gmail.com>)
Список pgsql-bugs
On Mon, 26 Jul 2021 at 23:53, Lætitia Avrot <laetitia.avrot@gmail.com> wrote:
> 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`:
>

I didn't find a SQL standard about `and chain`. IMO, whether the answer is
"yes" or "no", we should update the statistics. For notify, however, I'm not
sure.

>>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


--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.



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

Предыдущее
От: Alexander Lakhin
Дата:
Сообщение: Re: BUG #17116: Assert failed in SerialSetActiveSerXmin() on commit of parallelized serializable transaction
Следующее
От: "Andrey V. Lepikhov"
Дата:
Сообщение: Re: The case when AsyncAppend exists also in the qual of Async ForeignScan