On Thu, Mar 10, 2011 at 12:03 AM, Simon Riggs <simon@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
