Robert Haas <robertmh...@gmail.com> writes: > 1. Everything is humming along. > 2. The network link between the master and standby drops. > 3. Then it comes back up again. > > After (2) and before (3), what should the behavior the master be? It > seems clear to me that it should WAIT. Otherwise, a crash on the
That just means you want data high availability, not service HA. Some people want the *service* to stay available in such a situation. > master now leaves you with transactions that were confirmed committed > but not actually replicated to the standby. If you were OK with that > scenario, you would have used asynchronous replication in the first > place. What is so hard to understand in "worst case scenario" being different than "expected conditions". We all know that getting the last percent is more expensive than getting the 99 first one. We have no reason to force people into building for the last percent whatever their context. So, what cases need to be defined wrt forbidding the primary to continue alone? - in flight commit blocked until we can offer the asked for durability, wait forever - shutdown request blocked until standby acknowledge the final checkpoint are immediate shutdown requests permitted? what do they do? What other cases are to be fully designed here? Please note that above list is just a way to start the design, not a definitive proposal from me. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
