Tracking wait event for latches - Mailing list pgsql-hackers

From Michael Paquier
Subject Tracking wait event for latches
Date
Msg-id CAB7nPqTGhFOUHag1eJrvsKn8-E5fpqvhM7aL0tAfsDzjQG_YKQ@mail.gmail.com
Whole thread Raw
Responses Re: Tracking wait event for latches
Re: Tracking wait event for latches
List pgsql-hackers
Hi all,

As I mentioned $subject a couple of months back after looking at the
wait event facility here:
http://www.postgresql.org/message-id/CAB7nPqTJpgAvOK4qSC96Fpm5W+aCtJ9D=3Vn9AfiEYsur=-juw@mail.gmail.com
I have actually taken some time to implement this idea.

The particular case that I had in mind was to be able to track in
pg_stat_activity processes that are waiting on a latch for synchronous
replication, and here is what this patch gives in this case:
=# alter system set synchronous_standby_names = 'foo';
ALTER SYSTEM
=# select pg_reload_conf();
 pg_reload_conf
----------------
 t
(1 row)
=# -- Do something
[...]

And from another session:
=# select wait_event_type, wait_event from pg_stat_activity where pid = 83316;
 wait_event_type | wait_event
-----------------+------------
 Latch           | SyncRep
(1 row)

This is a boring patch, and it relies on the wait event facility that
has been added recently in 9.6. Note a couple of things though:
1) There is something like 30 code paths calling WaitLatch in the
backend code, all those events are classified and documented similarly
to LWLock events.
2) After discussing this stuff while at PGCon, it does not seem worth
to have any kind of APIs to be able to add in shared memory custom
latch names that extensions could load through _PG_init(). In
replacement to that, there is a latch type flag called "Extension"
that can be used for this purpose.
Comments are welcome, I am adding that in the 9.7 queue.

Regards,
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [PATCH] Add EXPLAIN (ALL) shorthand
Next
From: Евгений Шишкин
Date:
Subject: Re: [PATCH] Add EXPLAIN (ALL) shorthand