On Wed, Mar 2, 2011 at 3:45 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Simon Riggs <simon@2ndQuadrant.com> wrote:
>
>> allow_standalone_primary=off means "wait forever". It does nothing
>> to reduce data loss since you can't replicate to a server that
>> isn't there.
>
> Unless you're pulling from some persistent source which will then
> feel free to discard what you have retrieved. You can't assume
> otherwise; it's not that rare a pattern for interfaces. We use such
> a pattern for accepting criminal complaints from district attorneys
> and sending warrant information to police agencies. Waiting a long
> time (it won't *actually* be forever) is better than losing
> information.
>
> In other words, making a persistence promise which is not kept can
> lose data on the client side, if the clients actually trust your
> guarantees.
I agree. I assumed that when Simon was talking about removing
allow_standalone_primary, he meant making the code always behave as if
it were turned OFF. The common scenario here is bound to be:
1. Everything is humming along.
2. The network link between the master and standby drops.
3. Then it comes back up again.
After (2) and before (3), what should the behavior the master be? It
seems clear to me that it should WAIT. Otherwise, a crash on the
master now leaves you with transactions that were confirmed committed
but not actually replicated to the standby. If you were OK with that
scenario, you would have used asynchronous replication in the first
place.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
