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: making write location work (was: Efficient transaction-controlled synchronous replication) |
Date: | 2011-03-23 16:10:12 |
Message-ID: | AANLkTik5kbn+Y_xOuewdBpGQVS4EHoojAmi9nk14Y37M@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 23, 2011 at 3:35 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Mar 18, 2011 at 8:16 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Fri, Mar 18, 2011 at 3:52 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>>> I agree to get rid of write_location.
>>>
>>> No, don't remove it.
>>>
>>> We seem to be just looking for things to tweak without any purpose.
>>> Removing this adds nothing for us.
>>>
>>> We will have the column in the future, it is there now, so leave it.
>>
>> Well then can we revert the part of your patch that causes it to not
>> actually work any more?
>
> 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.
We don't know what the standby end will be doing with the data in all cases.
For the main server, making the additional change will just decrease
performance, for no benefit.
In the future we would have a parameter that says how often we send
replies, but there's no point having a parameter if there is only one
meaningful value for standby servers currently.
Please leave this as it is now.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-03-23 16:44:41 | Re: making write location work (was: Efficient transaction-controlled synchronous replication) |
Previous Message | Robert Haas | 2011-03-23 16:03:32 | Re: Comments on SQL/Med objects |