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

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)
Date: 2011-03-23 18:43:25
Message-ID: AANLkTinH9jcCK0Vr0hFW_xfCaXR5+EJwWKEins9RQivd@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 23, 2011 at 6:22 PM, 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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Susanne Ebrecht 2011-03-23 19:22:20 Re: psql \dt and table size
Previous Message Robert Haas 2011-03-23 18:25:51 Re: making write location work (was: Efficient transaction-controlled synchronous replication)