On Mon, Mar 28, 2011 at 3:11 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 28.03.2011 16:11, Simon Riggs wrote:
>>
>> On Mon, Mar 28, 2011 at 2:05 PM, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.com> wrote:
>>>
>>> It would feel at least as logical to control this in the standby.
>>
>> Now you are being ridiculous. You've spoken strongly against this at
>> every single step of this journey.
>
> I was thinking specifically about whether flush vs. write (vs. apply, maybe)
> here. It would make sense to set that in the standby. You might even want to
> set it differently on different standbys.
>
> What I was strongly against is the action at a distance, where setting a GUC
> in a standby suddenly makes the master to wait for acks from that server.
> That's dangerous, but I don't see such danger in setting the level of
> synchronicity in the standby, once you've decided that it's a synchronous
> standby.
The action at a distance thought still applies, since you would wait
more or less time depending upon how this parameter was set on the
standby.
I can't see how this situation differs. Your own argument still applies.
I would point out that I argued against you, but was persuaded towards
your approach. The code won't easily allow what you suggest. There
were multiple approaches to implementation, but there aren't anymore.
So you can't say the UI is unclear; its very clear how we implement
things from here - the way this patch implements it - on the master.
This is a simple patch, containing functionality already discussed and
agreed and for which code was submitted in this CF.
There's no reason to block this, only for us to decide the final
naming of parameter/s and options.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
