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.
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?
