On Wed, Feb 16, 2011 at 12:59 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Tue, Feb 15, 2011 at 9:41 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao <masao.fujii@gmail.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:
onceyou'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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company