On Wed, Sep 29, 2010 at 11:47 AM, Robert Haas <robertmh...@gmail.com> wrote: > So we've got two patches that implement synchronous replication, and > no agreement on which one, if either, should be committed. We have no > agreement on how synchronous replication should be configured, and at > most a tenuous agreement that it should involve standby registration. > > This is bad. > > This feature is important, and we need to get it done. How do we get > the ball rolling again?
ISTM that it still takes long to make consensus on standby registration. So, how about putting the per-standby parameters in recovery.conf, and focusing on the basic features in synchronous replication at first? During that time, we can deepen discussion on standby registration, and then we can implement that. The basic features that I mean is for most basic use case, that is, one master and one synchronous standby case. In detail, > * Support multiple standbys with various synchronization levels. Not required for that case. > * What happens if a synchronous standby isn't connected at the moment? Return > immediately vs. wait forever. The wait-forever option is not required for that case. Let's implement the return-immediately at first. > * Per-transaction control. Some transactions are important, others are not. Not required for that case. > * Quorum commit. Wait until n standbys acknowledge. n=1 and n=all servers can > be seen as important special cases of this. Not required for that case. > * async, recv, fsync and replay levels of synchronization. At least one of three synchronous levels should be included in the first commit. I think that either recv or fsync is suitable for first try because those don't require wake-up signaling from startup process to walreceiver and are relatively easy to implement. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
