Re: Change pg_last_xlog_receive_location not to move backwards

On Fri, Feb 11, 2011 at 12:52 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)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). We then change the walreceiver feedback
mechanism to use the term stream_location rather than write_location;
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.

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.

Thoughts, comments?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company