Re: Statistics updates is delayed when using `commit and chain`
От | Japin Li |
---|---|
Тема | Re: Statistics updates is delayed when using `commit and chain` |
Дата | |
Msg-id | MEYP282MB1669840B952A11A638AEAA67B6139@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM обсуждение исходный текст |
Ответ на | Re: Statistics updates is delayed when using `commit and chain` (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Statistics updates is delayed when using `commit and chain`
|
Список | pgsql-bugs |
On Mon, 12 Jul 2021 at 23:30, Tom Lane <tgl@sss.pgh.pa.us> wrote: > John Naylor <john.naylor@enterprisedb.com> writes: >> I understand this functionality to be tracking what happens at the physical >> level, in which case it is correct. In any case, the bug reported is clear >> and changing that behavior is the focus here. About the patch: > > 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. For example: ------------------------------------------------------------------------------ Step 1. Session 1: postgres# LISTEN tn; LISTEN Step 2. Session 2: postgers# CREATE TABLE tbl (id int) CREATE TABLE postgres=# BEGIN; BEGIN postgres=*# INSERT INTO tbl values (1); INSERT 0 1 postgres=*# NOTIFY tn, 'hello'; NOTIFY Step 3. Session 1: postgres=# SELECT * FROM tbl; id ---- (0 rows) Step 4. Session 2: postgres=*# COMMIT AND CHAIN; COMMIT Step 5. Session 1: postgres=# SELECT * FROM tbl; id ---- 1 (1 row) Step 6. Session 2: postgres=*# COMMIT; COMMIT Step 7. Session 1: postgres=# SELECT * FROM tbl; id ---- 1 (1 row) Asynchronous notification "tn" with payload "hello" received from server process with PID 16348. ------------------------------------------------------------------------------ Since we commit the data in step 4, however the notify doesn't handle, I think this is a bit confused. Why we must wait session is in idle to handle the notify? > Maybe you can persuade me that there's a reason to move the responsibility > for stats reporting to some other place, but please keep your hands > OFF of NOTIFY. You clearly haven't the faintest idea what the client > contract for that is. > > regards, tom lane -- Regrads, Japin Li. ChengDu WenWu Information Technology Co.,Ltd.
В списке pgsql-bugs по дате отправления: