Re: Additional options for Sync Replication

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Additional options for Sync Replication
Date: 2011-03-28 14:58:28
Message-ID: AANLkTi=ObJNO9kXMcqpXLiPjGdJruA_f6bPHTbUJFiKr@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 28, 2011 at 3:11 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 28.03.2011 16:11, Simon Riggs wrote:
>>
>> On Mon, Mar 28, 2011 at 2:05 PM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-03-28 15:01:47 Re: Additional options for Sync Replication
Previous Message Merlin Moncure 2011-03-28 14:54:51 Re: Recursive containment of composite types