On Thu, Mar 24, 2011 at 3:22 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Mar 23, 2011 at 12:10 PM, Simon Riggs <simon@2ndquadrant.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
