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

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company