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@gmail.com