On Fri, Dec 31, 2010 at 6:48 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > I suppose we might regard the feature set I am proposing as being the > same as making synchronous_standbys a USERSET parameter, and allowing > just two options: > "none" - allowing the user to specify async if they wish it > "*" - allowing people to specify that syncing to *any* standby is > acceptable > > We can blend the two approaches together, if we wish, by having two > parameters (plus server naming) > synchronous_replication = on | off (USERSET) > synchronous_standbys = '...' > If synchronous_standbys is not set and synchronous_replication = on then > we sync to any standby. If synchronous_replication = off then we use > async replication, whatever synchronous_standbys is set to. > If synchronous_standbys is set, then we use sync rep to all listed > servers. > > My proposal amounts to "lets add synchronous_standbys as a parameter in > 9.2".
FWIW, this plan of attack would be OK with me. I had taken your previous comments to imply that you were opposed to EVER having a parameter like this on the master, but I could see deferring it. In my ideal world, we'd not have the synchronous_replication_service parameter on the standbys at all - all standbys would be candidates, unless someone decides to name them and set synchronous_standbys on the master. But maybe having a simple on/off on the standby is reasonable. *thinks a little bit* Someone may have proposed this before, but one way of getting standby naming "for free" would be to make the standby names the same as the roles used to log in, rather than adding a separate parameter. We could just recommend to people that they use a separate, descriptive role name for each standby. Then the synchronous_standbys parameter - when added - would mean "a standby from one of these roles". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
