From: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Daniel Farina <daniel(at)heroku(dot)com> |
Subject: | Re: Sync Rep v17 |
Date: | 2011-03-02 15:37:25 |
Message-ID: | AANLkTinYDAHLMrGWpmOXfZnBbyzd5cHCsy4j=jgs9-H+@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 2, 2011 at 2:30 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)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(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Urbański | 2011-03-02 15:43:31 | Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) |
Previous Message | Tom Lane | 2011-03-02 15:28:00 | Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) |