Re: Sync Rep v17

Aidan Van Dyk <aidan@highrise.ca>

From: Aidan Van Dyk <aidan@highrise.ca>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, pgsql-hackers@postgresql.org, Daniel Farina <daniel@heroku.com>
Date: 2011-03-02T15:37:25Z
Lists: pgsql-hackers
On Wed, Mar 2, 2011 at 2:30 PM, Fujii Masao <masao.fujii@gmail.com> wrote:

> 1. The primary is running with allow_standalone_primary = on. There
>    is only one (synchronous) standby connected.

OK.  Explicitly configured to allow the master to report as commited
stuff which isn't on a/any slave.

> 7. New primary doesn't have some transactions committed to the
>    client, i.e., transaction lost happens!!

And this is a surprise?

I'm not saying there isn't a better way to to sequence/control a
shutdown to make this risk less, but isn't that the whole point of the
"allow_standalone_primary" debate/option?

"If there isn't a sync slave for whatever reason, just march on, I'll
deal with the transactions that are committed and not replicated some
other way".

I guess complaining that it shouldn't be possible to "just march on
when no sync slave is available" is one possible way oof "dealing
with" them ;-)

a.

-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.