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