On Fri, Jul 13, 2012 at 10:22 AM, Bruce Momjian <br...@momjian.us> wrote: > On Fri, Jul 13, 2012 at 09:12:56AM +0200, Hampus Wessman wrote: >> How you decide what to do with the servers on failures isn't that >> important here, really. You can probably run e.g. Pacemaker on 3+ >> machines and have it check for quorums to accomplish this. That's a >> good approach at least. You can still have only 2 database servers >> (for cost reasons), if you want. PostgreSQL could have all this >> built-in, but I don't think it sounds overly useful to only be able >> to disable synchronous replication on the primary after a timeout. >> Then you can never safely do a failover to the secondary, because >> you can't be sure synchronous replication was active on the failed >> primary... > > So how about this for a Postgres TODO: > > Add configuration variable to allow Postgres to disable synchronous > replication after a specified timeout, and add variable to alert > administrators of the change.
I agree we need a TODO for this, but... I think timeout-only is not the best choice, there should be a maximum timeout (as a last resource: the maximum time we are willing to wait for standby, this have to have the option of "forever"), but certainly PostgreSQL have to detect the *complete* disconnection of the standby (or all standbys on the synchronous_standby_names), if it detects that no standbys are eligible for sync standby AND the option to do fallback to async is enabled = it will go into standalone mode (as if synchronous_standby_names were empty), otherwise (if option is disabled) it will just continue to wait for ever (the "last resource" timeout is ignored if the fallback option is disabled).... I would call this "soft_synchronous_standby", and "soft_synchronous_standby_timeout" (in seconds, 0=forever, a sane value would be ~5 seconds) or something like that (I'm quite bad at picking names :( ). -- Ildefonso Camargo Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC @cmdpromptinc - 509-416-6579 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
