From: | Markus Wanner <markus(at)bluegap(dot)ch> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Yeb Havinga <yebhavinga(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: is sync rep stalled? |
Date: | 2010-10-04 07:49:02 |
Message-ID: | 4CA986EE.3050801@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/04/2010 09:18 AM, Heikki Linnakangas wrote:
> Note that this assumes that you use the 'replay' synchronization level.
> In the weaker levels, read-only queries can always return stale data.
I'm not too found of those various synchronization levels, but IIUC all
other levels only allow a rather limited staleness. But a master that's
continuing to commit new transactions with a disconnected standby that
happily continues to answer read-only queries, the age of the standby's
snapshot can grow without limitation.
> With 'replay' and hot standby combination, you'll want to set
> max_standby_archive_delay to a very low value, or a read-only query can
> cause master to stop processing commits (or the standby to stop
> accepting new queries, if that's preferred).
Well, given that DML-only transactions aren't prone such to conflicts, I
think of this as a corner case.
Also note, that this requirement seems to apply whether we wait forever
on standby failure or not. (Because even if we don't, there must be some
kind of timeout on the master from the very first suspicion to actually
declare the standby dead - anything else is called anync).
Regards
Markus Wanner
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-10-04 07:56:36 | Re: is sync rep stalled? |
Previous Message | Heikki Linnakangas | 2010-10-04 07:18:09 | Re: is sync rep stalled? |