Re: Change pg_last_xlog_receive_location not to move backwards

On Wed, Feb 16, 2011 at 7:06 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Feb 16, 2011 at 12:59 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Tue, Feb 15, 2011 at 9:41 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>>> 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.
>>>
>>> Well, my proposal was to expose it, on the theory that it's useful.
>>> As we stream the WAL, we write it, so I think for all intents and
>>> purposes write == stream.  But using it to convey the starting
>>> position makes more sense if you call it stream than it does if you
>>> call it write.
>>
>> Umm.. I could not find any use case to expose the WAL write location
>> besides flush one. So I'm not sure if it's really useful to track the
>> write location in the shmem besides the walreceiver-local memory.
>> What use case do you think of?
>
> Well, we're currently exposing that on the master via
> pg_stat_replication.  I guess we could rip that out, but I think that
> if nothing else we're imagining eventually supporting a sync rep mode
> where the standby acknowledges WAL upon receipt rather than upon
> write.  And the lag between the write and flush positions can be up to
> 16MB, so it doesn't seem entirely academic.  Basically, the write
> position is the most WAL that could be on disk on standby and the
> flush is the most WAL that we're SURE is on disk on the standby.
>
>> Personally the term "stream" sounds more ambiguous than "write".
>> I cannot imagine what location the pg_last_xlog_stream_location or
>> stream_location actually returns, from the function name;  WAL
>> location that has been received? written? flushed? replayed?
>> Since the "write" sounds cleaner, I like it.
>
> Well, the problem with receivedUpto is that it's really being used for
> two different things, neither of which is how much WAL has been
> received.  One is where streaming is to start (hence, stream) and the
> other is how much we've flushed to disk (hence, flush).  So you might
> think there were four positions: streaming start, write, flush, apply.
>  But I think the first two are really the same: once you've received
> at least one byte, the position that you're streaming from and the
> write position are the same, so I think the name stream can span both
> concepts.  OTOH, stream-start and flush are clearly NOT the same -
> there is a small but potentially significant delay between
> stream/write and flush.

It sounds like the only thing we have definite agreement about from
all this is that apply_location should be renamed to replay_location
in pg_stat_replication, a point fairly incidental to the what this
patch is about. It seems fairly unsatisfying to just change that and
punt the rest of this, but I'm not sure what the alternative is.

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