Re: pg_stat_replication log positions vs base backups

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_stat_replication log positions vs base backups
Date: 2015-12-16 10:14:54
Message-ID: CABUevEzCFMRbCnekvvK1jvQoDfB_8e-q6J2knDTUk5i-RF43HA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 16, 2015 at 8:34 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> On Mon, Dec 14, 2015 at 8:59 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
> > On Mon, Dec 14, 2015 at 1:01 AM, Magnus Hagander <magnus(at)hagander(dot)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?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2015-12-16 10:33:09 Re: pgbench stats per script & other stuff
Previous Message Simon Riggs 2015-12-16 10:08:16 Re: Experimental evaluation of PostgreSQL's query optimizer