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=-j...@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
wait-event-latch.patch
Description: invalid/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
