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`
|
Список | 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 по дате отправления: