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

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.

In response to

Responses

Browse pgsql-bugs by date

  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