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

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.

Regards,

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