Re: Additional options for Sync Replication

On Mon, Mar 28, 2011 at 10:11 AM, 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.

It might not be dangerous, but the standby currently sends write,
flush, and apply positions back separately, so the master must decide
which of those to pay attention to, unless we rework the whole design.
I actually think the current design is quite nice and am in no hurry
to rejigger that particular part of it. However, I do think that we
may need or want to rejigger the timing of replies for performance.
It might be, for example, that when waiting for the "write", the
master should somehow indicate to the standby the earliest write-LSN
that could release waiters, so that a standby can send back a reply
the instant it hits that LSN, without waiting to finish reading
everything that's buffered up as it does now. For apply, I agree with
your feeling that the startup process needs to wake walreceiver via a
latch when the apply position advances, but here again it might be
beneficial to send the first interesting LSN from master to standby to
cut down unnecessary wakeups. We also need to consider the issue
raised elsewhere - that a naive implementation of this could allow the
commit to become visible on the standby before it becomes visible on
the master. That would be expensive to prevent, because you'd need an
additional set of master-standby interlocks, but I think at least one
person was arguing that it was necessary for correctness - my memory
of the details is fuzzy at the moment.

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