Re: Change pg_last_xlog_receive_location not to move backwards

On Sat, 2011-02-12 at 09:32 -0500, Robert Haas wrote:
> On Fri, Feb 11, 2011 at 12:52 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > * Robert Haas (robertmhaas@gmail.com) wrote:
> >> Actually... wait a minute.  Now that I'm thinking about this a little
> >> more, I'm not so convinced.  If we leave this the way is, and just
> >> paper over the problem using the method Stephen and I both had in
> >> mind, then we could be streaming from a position that precedes the
> >> so-called "current" position.  And worse, the newly introduced replies
> >> to the master will still show the position going backward, so the
> >> master will reflect a position that is earlier that the position the
> >> slave reports for itself, not because of any real difference but
> >> because of a reporting difference.  That sure doesn't seem good.
> >
> > I'm really not sure it's as bad as all that...  The slave and the master
> > are only going to be "out of sync" wrt position until the slave sends
> > the request for update to the master, gets back the result, and checks
> > the XLOG header, right?
> 
> It'll restream the whole segment up to wherever it was, but basically, yes.
> 
> I think a big part of the problem here is that we have wildly
> inconsistent terminology for no especially good reason.  The standby
> reports three XLOG positions to the master, currently called write,
> flush, and apply.  The walreceiver reports positions called
> recievedUpTo and lastChunkStart.  receivedUpTo is actually the FLUSH
> position, and lastChunkStart is the previous flush position, except
> when the walreceiver first starts, when it's the position at which
> streaming is to begin.
> 
> So, what if we did some renaming?  I'd be inclined to start by
> renaming "receivedUpTo" to Flush, and add a new position called
> Stream.  When walreciever is started, we set Stream to the position at
> which streaming is going to begin (which can rewind) and leave Flush
> alone (so it never rewinds).

OK

>   We then change the walreceiver feedback
> mechanism to use the term stream_location rather than write_location;

OK

> and we could consider replacing pg_last_xlog_receive_location() with
> pg_last_xlog_stream_location() and pg_last_xlog_flush_location().
> That's a backward compatibility break, but maybe it's worth it for the
> sake of terminological consistency, not to mention accuracy.

Don't see a need to break anything. OK with two new function names.

> I'd also be inclined to go to the walreceiver code and and rename the
> apply_location to replay_location, so that it matches
> pg_last_xlog_replay_location().  The latter is in 9.0, but the former
> is new to 9.1, so we can still fix it to be consistent without a
> backward compatibility break.

Any renaming of things should be done as cosmetic fixes after important
patches are in.

-- Simon Riggs           http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services