Re: Issues with Quorum Commit

On 06.10.2010 01:14, Josh Berkus wrote:
>>> You start a new one from the latest base backup and let it catch up?
>>> Possibly modifying the config file in the master to let it know about
>>> the new standby, if we go down that path. This part doesn't seem
>>> particularly hard to me.
>>
>> Agreed, not sure of the issue there.
>
> See previous post.  The critical phrase is *without restarting the
> master*.  AFAICT, no patch has addressed the need to change the master's
> synch configuration without restarting it.  It's possible that I'm not
> following something, in which case I'd love to have it pointed out.

Fair enough. I agree it's important that the configuration can be 
changed on the fly. It's orthogonal to the other things discussed, so 
let's just assume for now that we'll have that. If not in the first 
version, it can be added afterwards. "pg_ctl reload" is probably how it 
will be done.

There is some interesting behavioral questions there on what happens 
when the configuration is changed. Like if you first define that 3 out 
of 5 servers must acknowledge, and you have an in-progress commit that 
has received 2 acks already. If you then change the config to "2 out of 
4" servers must acknowledge, is the in-progress commit now satisfied? From the admin point of view, the server that was
removedfrom the 
 
system might've been one that had acknowledged already, and logically in 
the new configuration the transaction has only received 1 acknowledgment 
from those servers that are still part of the system. Explicitly naming 
the standbys in the config file would solve that particular corner case, 
but it would no doubt introduce other similar ones.

But it's an orthogonal issue, we'll figure it out when we get there.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com