On Fri, Jul 13, 2012 at 12:25 AM, Amit Kapila <amit.kap...@huawei.com> wrote: > >> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] >> On Behalf Of Jose Ildefonso Camargo Tolosa >>>On Thu, Jul 12, 2012 at 9:28 AM, Aidan Van Dyk <ai...@highrise.ca> wrote: >> On Thu, Jul 12, 2012 at 9:21 AM, Shaun Thomas <stho...@optionshouse.com> > wrote: >> > >> As currently is, the point of: freezing the master because standby >> dies is not good for all cases (and I dare say: for most cases), and >> having to wait for pacemaker or other monitoring to note that, change >> master config and reload... it will cause a service disruption! (for >> several seconds, usually, ~30 seconds). > > Yes, this is true that it can cause service disruption, but the same will be > True even if master detects that internally by having timeout. > By keeping this as external, the current behavior of PostgreSQL can be > maintained that > if there is no standy in sync mode, it will wait and still serve the purpose > as externally it can send message for master. >
How does currently PostgreSQL detects that its main synchronous standby went away and switch to another synchronous standby on the synchronous_standby_names config parameter? The same logic could be applied to "no more synchronous standbys: go into standalone" (optionally). -- 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
