From: | Japin Li <japinli(at)hotmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Lætitia Avrot <laetitia(dot)avrot(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Statistics updates is delayed when using `commit and chain` |
Date: | 2021-07-14 01:55:42 |
Message-ID: | MEYP282MB1669840B952A11A638AEAA67B6139@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, 12 Jul 2021 at 23:30, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> John Naylor <john(dot)naylor(at)enterprisedb(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2021-07-14 02:12:14 | Re: BUG #17103: WAL segments are not removed after exceeding max_slot_wal_keep_size |
Previous Message | Peter Geoghegan | 2021-07-13 23:02:46 | Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows |