On Wed, Dec 16, 2015 at 9:35 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Wed, Dec 16, 2015 at 7:14 PM, Magnus Hagander <mag...@hagander.net> wrote: >> On Wed, Dec 16, 2015 at 8:34 AM, Michael Paquier <michael.paqu...@gmail.com> >> wrote: >>> Interesting. I got just today a bug report that is actually a symptom >>> that people should be careful about: it is possible that >>> pg_stat_replication reports 1/potential for sync_priority/sync_state >>> in the case of a WAL sender in "backup" state: a base backup just >>> needs to reuse the shared memory slot of a standby that was previously >>> connected. Commit 61c7bee of Magnus fixes the issue, just let's be >>> careful if there are similar reports that do not include this fix. >> >> >> Hmm. With the fix, it returns "async", right? > > Yes, it returns async with priority set at 0 after your commit. That's > a bit better than the old behavior, still.. > >> Perhaps it should return either "backup" or NULL, to be even more clear? And >> with priority set to NULL? > > I'd vote for just NULL for both fields. This async/sync status has no > real sense for a backup. Thoughts?
While looking again at that, considering a WAL sender having an invalid WAL flush position as always asynchronous like a base backup one is directly mentioned in walsender.c, per 0c4b468: + /* + * Treat a standby such as a pg_basebackup background process + * which always returns an invalid flush location, as an + * asynchronous standby. + */ The point is just to be sure that such a node won't be selected as a sync standby, while it is a surprising behavior, but after this many years it may not be worth switching to NULL values. Fujii-san, thoughts? You introduced this behavior after all. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers