Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)
Date
Msg-id AANLkTimv_Xoq1yH0fAw+G-fEXTaKAoCsOW9qgOQfiD0d@mail.gmail.com
Whole thread Raw
In response to making write location work (was: Efficient transaction-controlled synchronous replication)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)
List pgsql-hackers
On Wed, Mar 23, 2011 at 2:43 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> 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.

Oh, really?  Is this strictly hypothetical or is such a beast
planned/already in existence?

I'm just afraid this is going to be confusing to users who will expect
it to do something that it doesn't.

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


pgsql-hackers by date:

Previous
From: Susanne Ebrecht
Date:
Subject: Re: psql \dt and table size
Next
From: Simon Riggs
Date:
Subject: Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)