Re: pg_stat_replication log positions vs base backups - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: pg_stat_replication log positions vs base backups
Date
Msg-id CABUevEzCFMRbCnekvvK1jvQoDfB_8e-q6J2knDTUk5i-RF43HA@mail.gmail.com
Whole thread Raw
In response to Re: pg_stat_replication log positions vs base backups  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: pg_stat_replication log positions vs base backups  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Wed, Dec 16, 2015 at 8:34 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Mon, Dec 14, 2015 at 8:59 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Mon, Dec 14, 2015 at 1:01 AM, Magnus Hagander <magnus@hagander.net> wrote:
>> I've applied these two patches now.
>>
>> The one that fixes the initialization backpatched to 9.3 which is the oldest
>> one that has it, and the one that changes the actual 0-vs-NULL output to 9.5
>> only as it's a behaviour change.
>
> Thanks!

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?

Perhaps it should return either "backup" or NULL, to be even more clear? And with priority set to NULL? 


--

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Experimental evaluation of PostgreSQL's query optimizer
Next
From: Fabien COELHO
Date:
Subject: Re: pgbench stats per script & other stuff