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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to