On Wed, Mar 23, 2011 at 6:22 PM, 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.
No its not.
> 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.
As of 9.1, we now support other tools that use the protocol, so you
cannot assume you know what is being sent, just because one sender has
certain characteristics.
> 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.
They can be in 9.1 and almost certainly will be in 9.2
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services