From: | Benoit Lobréau <benoit(dot)lobreau(at)dalibo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, msalais(at)msym(dot)fr |
Cc: | 'Rajesh Kumar' <rajeshkumar(dot)dba09(at)gmail(dot)com>, pgsql-admin(at)lists(dot)postgresql(dot)org |
Subject: | Re: Commit with wait event on advisory lock! |
Date: | 2025-02-04 15:22:45 |
Message-ID: | aeb7adb1-1a2a-4f50-a24f-40fd4da60299@dalibo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On 1/22/25 11:17 PM, Tom Lane wrote:
>> By the way I also have commits which are waiting on ClientRead...
>
> That, on the other hand, is surely impossible. I think maybe you
> are misreading the stats display. Typically I'd expect that such a
> case indicates that the session is idle (awaiting a new command)
> and the COMMIT is the last thing it did before that.
>
> regards, tom lane
I can reproduce the issue using pgbench spamming "BEGIN; COMMIT;" and
and running this query in psql:
SELECT DISTINCT state, wait_event, query
FROM pg_stat_activity
WHERE backend_type ILIKE '%client%'
AND query ILIKE 'COMMIT%'
\watch 0.5
After a short while I get the following :
active | ClientRead | COMMIT;
I looked into src/backend/utils/adt/pgstatfuncs.c and found that
the state comes from the PgBackendStatus array, while the wait
events are fetched from the proc array (using st_procpid taken
from the backend status).
I don't think there is a guarantee that this "snapshot" is
consistent across both arrays. It might just be a case of spamming
pg_stat_activity and occasionally ending up with an "inconsistent
snapshot."
Do you think this explanation holds weight?
I haven't been able to reproduce the advisory lock issue yet.
--
Benoit Lobréau
Consultant
http://dalibo.com
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Urones | 2025-02-04 15:57:55 | Partition table with a foreign key self-reference |
Previous Message | di.liu | 2025-02-03 01:45:47 | RE: PostgreSQL Timeline Issue After Switchover with Pacemaker |