On Thu, Mar 10, 2011 at 12:03 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On Wed, 2011-03-09 at 15:37 +0100, Yeb Havinga wrote: > >> The current situation is definately unsafe because it forces people >> that are in this state to do a fast shutdown.. but that fails as well, >> so they are only left with immediate.
I agree with Yeb. > All the more reason not to change anything, since we disagree. > > The idea is that you're supposed to wait for the standby to come back up > or do failover. If you shutdown the master its because you are choosing > to failover. > > Shutting down the master and restarting without failover leads to a > situation where some sync rep commits are not on both master and > standby. Making it easier to shutdown encourages that, which I don't > wish to do, at this stage. I'm not sure I follow you. The proposed fast shutdown prevents the backends which have not received the ACK from the standby yet from returning the "success" to the client. So even after restarting the server, there is no data loss from client's point of view. If this is really unsafe, we *must* forbid immediate shutdown while backend is waiting for sync rep. Because immediate shutdown creates the same situation. What scenario are you concerned? > We may decide that this is the right approach but I don't wish to rush > into that decision. I want to have clear agreement about all the changes > we want and what we call them if we do them. Zero data loss is > ultimately about users having confidence in us, not about specific > features. Our disagreements on this patch risk damaging that confidence, > whoever is right/wrong. Same as above. I think that it's more problematic to leave the code as it is. Because smart/fast shutdown can make the server get stuck until immediate shutdown is requested. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
