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.