Re: pg_stat_replication log positions vs base backups

On Fri, Nov 27, 2015 at 6:07 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> On Thu, Nov 26, 2015 at 10:53 PM, Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
> > On Thu, Nov 26, 2015 at 1:03 PM, Michael Paquier <
> michael(dot)paquier(at)gmail(dot)com>
> > wrote:
> >>
> >> On Thu, Nov 26, 2015 at 6:45 PM, Magnus Hagander wrote:
> >> > I'm only talking about the actual value in pg_stat_replication here,
> not
> >> > what we are using internally. These are two different things of
> course -
> >> > let's keep them separate for now. In pg_stat_replication, we
> explicitly
> >> > check for InvalidXLogRecPtr and then explicitly set the resulting
> value
> >> > to
> >> > NULL in the SQL return.
> >>
> >> No objections from here. I guess you already have a patch?
> >
> > Well, no, because I haven't figured out which way is the logical one -
> make
> > them all return NULL or make them all return 0/0...
>
> It seems to me that NULL is the logical one. We want to define a value
> from the user prospective where things are in an undefined state.
> That's my logic flow, other opinions are of course welcome.
>

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.

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