Re: is sync rep stalled?

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

In response to

Responses

Browse pgsql-hackers by date

  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?