On Wed, Sep 1, 2010 at 2:33 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > Once we're done with that, all the big questions are still left.
Yeah, let's discuss about those topics :) > How to configure it? Before discussing about that, we should determine whether registering standbys in master is really required. It affects configuration a lot. Heikki thinks that it's required, but I'm still unclear about why and how. Why do standbys need to be registered in master? What information should be registered? > What does synchronous replication mean, when is a transaction > acknowledged as committed? I proposed four synchronization levels: 1. async doesn't make transaction commit wait for replication, i.e., asynchronous replication. This mode has been already supported in 9.0. 2. recv makes transaction commit wait until the standby has received WAL records. 3. fsync makes transaction commit wait until the standby has received and flushed WAL records to disk 4. replay makes transaction commit wait until the standby has replayed WAL records after receiving and flushing them to disk OTOH, Simon proposed the quorum commit feature. I think that both is required for various our use cases. Thought? > What to do if a standby server dies and never > acknowledges a commit? The master's reaction to that situation should be configurable. So I'd propose new configuration parameter specifying the reaction. Valid values are: - standalone When the master has waited for the ACK much longer than the timeout (or detected the failure of the standby), it closes the connection to the standby and restarts transactions. - down When that situation occurs, the master shuts down immediately. Though this is unsafe for the system requiring high availability, as far as I recall, some people wanted this mode in the previous discussion. 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
