Re: pg_stat_replication log positions vs base backups

On Wed, Nov 25, 2015 at 3:03 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

>
>
> On Wed, Nov 25, 2015 at 7:18 PM, Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
>
>>
>> On Wed, Nov 25, 2015 at 10:19 AM, Magnus Hagander <magnus(at)hagander(dot)net>
>> wrote:
>>
>>> Are the values for the log locations really relevant for backup
>>> connections? And if they are, we need to document it :) ISTM we are just
>>> more or less leaking random data out there?
>>>
>>> I'm talking about the actual state=backup connection - not the
>>> connection if we're using -x with pg_basebackup. Where we have output like:
>>>
>>> state | backup
>>> sent_location | 0/0
>>> write_location | 2/76CE0000
>>> flush_location | 2/76CC0000
>>> replay_location | 2/76CBF938
>>>
>>> I'm thinking those fields should probably all be NULL for state=backup?
>>>
>>
> Hm. You would basically get that when a backup WAL sender is reusing the
> sender of another node that is not here anymore.
>

Yeah - and that's obviously incorrect.

> In particular, it seems that in InitWalSenderSlot, we only initialize the
>> sent location. Perhaps this is needed?
>>
>
> Yes, that would be nice to start with a clean state. At the same time, I
> am noticing that pg_stat_get_wal_senders() is comparing flush, apply and
> write directly with 0. I think those should be InvalidXLogRecPtr. Combined
> with your patch it gives the attached.
>

Good point.

Another thought - why do we leave 0/0 in sent location, but turn the other
three fields to NULL if it's invalid? That seems inconsistent. Is there a
reason for that, or should we fix that as well while we're at it?

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