On Wed, Nov 25, 2015 at 3:03 PM, Michael Paquier <michael.paqu...@gmail.com> wrote:
> > > On Wed, Nov 25, 2015 at 7:18 PM, Magnus Hagander <mag...@hagander.net> > wrote: > >> >> On Wed, Nov 25, 2015 at 10:19 AM, Magnus Hagander <mag...@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? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
