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

From Simon Riggs
Subject Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)
Date
Msg-id AANLkTi=tBMFEhCKy3L6F7FOtg-2o0E32BYAiN1n04OZB@mail.gmail.com
Whole thread Raw
In response to Re: Re: 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 7:29 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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?

Ask Magnus.

In any case, that's not the only argument for keeping it. We introduce
the view in this release and I would like it to stay the same from
now, since we know we will need that info later.

No more minor tweaks, please.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)
Next
From: Robert Haas
Date:
Subject: Re: 2nd Level Buffer Cache