On Fri, Jul 21, 2006 at 03:23:09AM +0200, Florian G. Pflug wrote:
> Not only a small value IMHO. Doing schema changes is a major PITA
> right now - and it's very easy to shoot yourself in the foot. I'd
> welcome anything that improves that situation.
Are you sure this will be an improvement? It might just be a
foot-gun of a different calibre.
Remember, Slony-I can replicate across slow links too. Are you sure
you want to have a lock persist over several minutes?
What about if you're in an emergency where (1) your remote site is
down and (2) you've just discovered a bug that requires a schema
change to fix. I know, I know, can't happen, right?
> 1) When doing execute script, first submit a "try execute script" event.
> 2) All nodes do "begin; <submitted script>".
> < 8.1: If there is no error, they ack the event with "ok", and _ROLLBACK_
> (!).
> If there is an error, they ack the event with "failed", and
> ROLLBACK.
> <= 8.1: If there is no error, they ack the event with "ok", and "PREPARE".
> If there is an error, the ack the event with "failed" and
> ROLLBACK.
> 3) If all nodes acked with "ok", then "execute script" event is generated,
> referencing
> the previous "try" event.
And what about the case where node, say, 4 has just not replied yet.
Everybody is stuck in PREPARE mode here, and they might still roll
back.
> Maybe the user could even choose _not_ use 2pc on 8.1, to avoid the
> heavy locking that 2pc brings.
I think it's a non-starter without that escape valve. But I'm
concerned now that the system becomes pretty complex, and therefore
prone to bugs. I'd like to see a simple mechanism, all things
considered.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Unfortunately reformatting the Internet is a little more painful
than reformatting your hard drive when it gets out of whack.
--Scott Morris
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
