On 01/01/2011 05:55 PM, Simon Riggs wrote:
On Sat, 2011-01-01 at 16:12 +0100, Stefan Kaltenbrunner wrote:
I still would like to get a statement on why simon thinks that
the design heikki and others have proposed
I've explained in huge detail why I think what I think, nor avoided any
technical issue.
It appears to me there has been substantial confusion over alternatives,
because of a misunderstanding about how synchronisation works. Requiring
confirmation that standbys are in sync is *not* the same thing as them
actually being in sync. Every single proposal made by anybody here on
hackers that supports multiple standby servers suffers from the same
issue: when the primary crashes you need to work out which standby
server is ahead.
aaah that was exactly what I was after - so the problem is that when you
have a sync standby it will technically always be "in front" of the
master (because it needs to fsync/apply/whatever before the master).
In the end the question boils down to what is "the bigger problem" in
the case of a lost master:
a) a transaction that was confirmed on the master but might not be on
any of the surviving sync standbys (or you will never know if it is) -
this is how I understand the proposal so far
b) a transaction that was not yet confirmed on the master but might have
been applied on the surving standby before the desaster - this is what I
understand "confirm from all sync standbys" could result in.
Spelled out that more clearly now makes me a bit reconsider on what I
said before but I still wonder if ultimately we will have to provide
both modes to satisfy different business requirements (a might provide
the more accurate answer on average but b might at least provide a way
to identify the "wild" transaction buy looking at additional data)
- The docs should not allege that either setup is preferable to the
other, because there is not now and will never be consensus that this
is in fact true.
I remain hopeful that people will read what I have read and understand
it. Having taken the trouble to do that publicly, my conscious is clear
that I've done the very best to explain things and make it easy for
users to avoid error. If I am prevented from putting sound advice into
the docs, I'll not worry too much.
well I should think we need to clearly spell out everything that affects
reliability and if we only support semi-sync for more than 1 standby we
have only that setup :)
You can use sync rep with 1 or more standby servers.
At the end of the day, I can't stop anyone from saying "What an idiot,
he designed something that gave the same durability and availability as
Oracle and MySQL do, yet with additional performance management
features".
ok
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
