On 5/29/17 21:38, Noah Misch wrote: >> Actually, now that I look at it, ready_to_display should as well be >> protected by the lock of the WAL receiver, so it is incorrectly placed >> in walreceiver.h. As you are pointing out, pg_stat_get_wal_receiver() >> is lazy as well, and that's new in 10, so we have an open item here >> for both of them. And I am the author for both things. No issues >> spotted in walreceiverfuncs.c after review. >> >> I am adding an open item so as both issues are fixed in PG10. With the >> WAL sender part, I think that this should be a group shot. >> >> So what do you think about the attached? > > [Action required within three days. This is a generic notification.] > > The above-described topic is currently a PostgreSQL 10 open item. Peter, > since you committed the patch believed to have created it, you own this open > item.
I don't think this is my item. Most of the behavior is old, and pg_stat_get_wal_receiver() is from commit b1a9bad9e744857291c7d5516080527da8219854. (The logical replication equivalent of that is pg_stat_get_subscription(), which does appear to use appropriate locking.) I would appreciate if another committer can take the lead on this. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
