Re: Change pg_last_xlog_receive_location not to move backwards

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?

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.

Regards,

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