On Fri, Dec 31, 2010 at 6:48 AM, Simon Riggs <simon@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
