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 CABUevEw8_YS6Qho3oBy6gd4qngLNio46j=kyAwAViOfvUVYH0Q@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
List pgsql-hackers


On Fri, Nov 27, 2015 at 6:07 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Thu, Nov 26, 2015 at 10:53 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Thu, Nov 26, 2015 at 1:03 PM, Michael Paquier <michael.paquier@gmail.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. 

--

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: strange CREATE INDEX tab completion cases
Next
From: Mark Dilger
Date:
Subject: Re: Using a single standalone-backend run in initdb (was Re: Bootstrap DATA is a pita)