Re: Change pg_last_xlog_receive_location not to move backwards

On Sat, Feb 12, 2011 at 11:32 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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().

You suggest that the shared variable Stream tracks the WAL write location,
after it's set to the replication starting position? I don't think
that the write
location needs to be tracked in the shmem because other processes than
walreceiver don't use it.

What I proposed is:

Walreceiver-local variables
==================
1. LogstreamResult.Write
     - Indicates the location of recently written WAL record
     - Can rewind
     - pg_stat_replication.write_location returns this

2. LogstreamResult.Flush
     - Indicates the location of recently flushed WAL record
     - Can rewind
     - pg_stat_replication.flush_location returns this

Shmem variables
===========
3. WalRcv->receiveStart
     - Indicates the replication starting location
     - Updated only when walreceiver is started
     - Doesn't exist at the moment, so I propose to add this

4. WalRcv->receivedUpto
     - Indicates the latest location of all the flushed WAL records
     - Never rewinds
        (Can rewind at the moment, so I propose to prevent the rewind)
     - pg_last_xlog_receive_location returns this

You propose to rename LogstreamResult.Write to .Stream, and
merge it and receiveStart?

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

+1

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center