Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)

On Thu, Mar 24, 2011 at 11:45 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Thu, Mar 24, 2011 at 3:22 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Wed, Mar 23, 2011 at 12:10 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>>> Specifically, if we're not going to remove write location, then I
>>>> think we need to apply something like the attached.
>>>
>>> The protocol supports different write/fsync values, so the view should
>>> display them.
>>
>> That's exactly the point.  Currently, we have a protocol that supports
>> different write and fsync values, but the code as written does not
>> actually ever send a reply at any time when the two values can ever be
>> different.  So there is no point in sending both of them.  The write
>> location is completely redundant with the fsync location and therefore
>> completely useless.  We shouldn't bother sending the value twice, or
>> displaying it twice, if it's absolutely 100% guaranteed to be
>> identical in every case.
>>
>> The point of the patch that I posted is that it restores the previous
>> behavior, where we send an update before flushing WAL and again after
>> flushing WAL.  If we do that, then the write location can be ahead of
>> the flush location when we've written but not flushed.  If we don't do
>> that, and only send replies after flushing everything, then the two
>> fields are perforce always the same on the master.  I don't see that
>> as being a useful behavior, and in fact I think it could be quite
>> confusing.  Someone might assume that if we bother to expose both a
>> write_location and a flush_location, they are somehow different.
>
> I agree with Robert. It's useless and confusing to send the same
> location as flush_location as write_location redundantly. We should
> either remove write_location from the pg_stat_replication view and
> the protocol at all, or apply the proposed patch.

You may be confused, but that doesn't mean its useless.

The protocol supports sending two values, so two are displayed.

If you wish to remove one from the display then that only makes sense
if you also prevent the protocol from supporting two values.

There is no benefit in doing that, so why do it? We are going to put
that back in 9.2 if you remove it now. Why not leave it, so we don't
need to rewrite all the monitoring tools that will use this view?

Just say this in the docs. "Currently, standbys return the same value
for write and flush locations and so in most cases these values will
be the same. It is possible to write a user program that sends replies
at different times and in that case the values would differ. In later
release these values will differ for standbys. when more options are
available."

It's almost certain that Magnus will fix the bug in pg_xlogstream (or
whatever its called) and a tool will be available, so lets leave this.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services