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.