Re: pg_stat_replication log positions vs base backups - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_stat_replication log positions vs base backups
Date
Msg-id CAB7nPqSxt96ygwnaOj_3dgB9o_cxDr_Gm5es0WSDAFkDqW9YgQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_stat_replication log positions vs base backups  (Magnus Hagander <magnus@hagander.net>)
Responses Re: pg_stat_replication log positions vs base backups  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers


On Wed, Nov 25, 2015 at 7:18 PM, Magnus Hagander <magnus@hagander.net> wrote:

On Wed, Nov 25, 2015 at 10:19 AM, Magnus Hagander <magnus@hagander.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.
 
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.
--
Michael
Attachment

pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: custom function for converting human readable sizes to bytes
Next
From: Magnus Hagander
Date:
Subject: Re: pg_stat_replication log positions vs base backups