On Fri, Sep 17, 2010 at 8:31 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > The only thing standby registration allows you to do is know whether > there was supposed to be a standby there, but yet it isn't there now. I > don't see that point as being important because it seems strange to me > to want to wait for a standby that ought to be there, but isn't anymore.
According to what I heard, some people want to guarantee that all the transactions are *always* written in *all* the synchronous standbys. IOW, they want to keep the transaction waiting until it has been written in all the synchronous standbys. Standby registration is required to support such a use case. Without the registration, the master cannot determine whether the transaction has been written in all the synchronous standbys. > What happens if it never comes back? Manual intervention required. Yep. > In the use cases we discussed we had simple 2 or 3 server configs. > > master > standby1 - preferred sync target - set to recv, fsync or apply > standby2 - non-preferred sync target, maybe test server - set to async > > So in the two cases you mention we might set > > "wait for ack from reporting slave" > master: sync_replication = 'recv' #as default, can be changed > reporting-slave: sync_replication_service = 'recv' #gives max level > > "wait until replayed in the server on the west coast" > master: sync_replication = 'recv' #as default, can be changed > west-coast: sync_replication_service = 'apply' #gives max level What synchronization level does each combination of sync_replication and sync_replication_service lead to? I'd like to see something like the following table. sync_replication | sync_replication_service | result ------------------+--------------------------+-------- async | async | ??? async | recv | ??? async | fsync | ??? async | apply | ??? recv | async | ??? ... 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
