|From:||Michael Paquier <michael(dot)paquier(at)gmail(dot)com>|
|To:||PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Tracking wait event for latches|
|Views:||Raw Message | Whole Thread | Download mbox|
As I mentioned $subject a couple of months back after looking at the
wait event facility here:
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';
=# select pg_reload_conf();
=# -- 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
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.
|Next Message||Евгений Шишкин||2016-05-19 20:17:12||Re: [PATCH] Add EXPLAIN (ALL) shorthand|
|Previous Message||Peter Geoghegan||2016-05-19 20:02:12||Re: [PATCH] Add EXPLAIN (ALL) shorthand|