On Thu, Dec 30, 2010 at 2:04 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > We use a single parameter to enable synchronous replication, set in > postgresql.conf on both primary and standby servers: > > synchronous_replication = off (default) | on > > On the primary, synchronous_replication can be set for particular users > or databases, or dynamically by applications programs. > > If more than one standby server specifies synchronous_replication, then > whichever standby replies first will release waiting commits. > > Turning this setting off for a standby allows the administrator to > exclude certain standby servers from releasing waiting transactions. > This is useful if not all standby servers are designated as potential > future primary servers. On the standby, this parameter only takes effect > at server start.
I think it's a bad idea to use the same parameter to mean different things on the master and standby. You proposed this kind of double meaning for the hot_standby parameter (possibly back when it was called standby_connections, or something like that) and we (rightly, I think) did not adopt that, instead ending up with wal_level to control the master's behavior and hot_standby to control the slave's behavior. > synchronous_replication (boolean) > Specifies whether transaction commit will wait for WAL records > to be replicated before the command returns a "success" > indication to the client. The word "replicated" here could be taken to mean different things, most obviously: - slave has received the WAL - slave has fsync'd the WAL - slave has applied the WAL -- 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
