Re: Additional options for Sync Replication - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Additional options for Sync Replication |
Date | |
Msg-id | AANLkTik-+PTP8aku0rS=ZDWK6wQESxNYVt81VsoanpCy@mail.gmail.com Whole thread Raw |
In response to | Re: Additional options for Sync Replication (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Responses |
Re: Additional options for Sync Replication
Re: Additional options for Sync Replication |
List | pgsql-hackers |
On Mon, Mar 28, 2011 at 10:11 AM, 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. 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 andam 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
pgsql-hackers by date: