On Monday, February 27, 2012 4:36:26 pm Jameison Martin wrote: > I have observed that a commit on a replication master hangs if there are no > slaves to communicate with if synchronous replication is enabled. I > believe I have seen a posting that this behavior is deliberate. > > In my environment I'd prefer to have the master continue processing > transactions if there is a failure at the slave. Questions: * is there any > way to allow the master proceed if the slave is unavailable (perhaps a > configuration parameter I'm missing)? http://www.postgresql.org/docs/9.1/interactive/runtime-config-wal.html#GUC- SYNCHRONOUS-COMMIT " If synchronous_standby_names is set, this parameter also controls whether or not transaction commit will wait for the transaction's WAL records to be flushed to disk and replicated to the standby server. The commit wait will last until a reply from the current synchronous standby indicates it has written the commit record of the transaction to durable storage. If synchronous replication is in use, it will normally be sensible either to wait both for WAL records to reach both the local and remote disks, or to allow the transaction to commit asynchronously. However, the special value local is available for transactions that wish to wait for local flush to disk, but not synchronous replication. " > > * if not, is there any ideological objection to allowing the master to > continue for users that would prefer that behavior? Thanks. Seems to me to defeat the purpose of sync replication. Though if you want, beside the above: " Even when synchronous replication is enabled, individual transactions can be configured not to wait for replication by setting the synchronous_commit parameter to local or off. " Though it looks like you are really looking for async streaming replication. -- Adrian Klaver adrian.klaver@xxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
