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  | ajs at crankycanuck.ca
Unfortunately reformatting the Internet is a little more painful 
than reformatting your hard drive when it gets out of whack.
		--Scott Morris