Hello Dimitri, On 10/06/2010 05:41 PM, Dimitri Fontaine wrote: > - when do you start considering the standby as a candidate to your sync > rep requirements?
That question doesn't make much sense to me. There's no point in time I ever mind if a standby is a "candidate" or not. Either I want to synchronously replicate to X standbies, or not. > Lots of the discussion we're having are taking as an implicit that the > answer is "as soon as you know about its existence, that must be at the > pg_start_backup() point". This is an admin decision. Whether or not your standbies are up and running or not, existing or just about to be bought, that doesn't have any impact on your durability requirements. If you want your banking accounts data to be saved in at least two different locations, I think that's your requirement. You'd be quite unhappy if your bank lost your last month's salary, but stated: "hey, at least we didn't have any downtime". > And you can offer an option to guarantee the wait-forever behavior only > when it makes sense, rather than trying to catch your own tail as soon > as a standby is added in the mix Of course, it doesn't make sense to wait-forever on *every* standby that ever gets added. Quorum commit is required, yes (and that's what this thread is about, IIRC). But with quorum commit, adding a standby only improves availability, but certainly doesn't block the master in any way. (Quite the opposite: it can allow the master to continue, if it has been blocked before because the quorum hasn't been reached). Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
