On Wed, Jul 26, 2006 at 04:40:40PM +0200, Florian G. Pflug wrote:
> 
> I'd be an _optional_ feature to use. Nobody would force _anyone_
> to use 2pc schema updates. But some people, like e.g. I, _could_

But you're forcing the entire project to maintain that code.  That's
not nothing.  It's a trade off.  

Again, I'm not saying it's not worth it; I'm rather asking whether
there isn't something that can address the actual problem you have --
dangerous schema changes -- more completely.  I'll note that you
simply didn't respond to my argument that perhaps this is better
solved by improved administration tools, which is what the real
problem is anyway.

> That worst case would only happen if you lost then network connection
> to a node while the schema change is still running. 

No.  It could happen in cases where there are bugs on the remote
node.  Or where a disk failure happens.  Or where a memory chip
corrupts things.  Or more or less any case of hard failure of one
node in the system.  And. . .

> Logging into all nodes and doing "rollback <transaction>" is just
> a minor nuisance compared to resubscribing all sets.

. . , the problem is that _everyone_ is stuck in prepare mode until
you know what you're going to do here, and that prepared transaction
will block _every transaction_ on the affected table on each node
until the transaction is either committed or rolled back on the
respective node.  (So it's not blocked cluster-wide, but blocked per
node, depending on whether the COMMIT/ROLLBACK TRANSACTION has worked
or not.)  The locks have to persist.  It is not as lightweight as
you're making it out to be.

> Automating this recovery is possible in theory - but it requires
> slonik to remeber if step (5)) was successfull on all nodes, or
> not.

And this is my point.  I completely fail to see how this failure mode
is in any way better than any other.  It's still confusing to users,
and can easily block transactions on the origin for long periods of
time.  One of the advantages of Slony-I is supposed to be that it's
asynchronous.  But this proposal makes DDL synchronous across a
cluster in cases where it is used.  I think that we need to work out
very carefully how this might fail, and how to automate recovery from
such failures, before we do it.  If the idea is to implement new
features in order to solve the shortcomings of slonik, let's have at
least a plan for getting all the way there.

Remember, slonik was never intended to be the final admnistrative
interface for Slony.  It was a quick job, put together to make it
possible to administer the system given a fairly detailed knowledge
of how the system works.  The idea was always that administrative
interfaces would emerge from the community of users to solve the
administrative problems that, frankly, those who already understood
the sytem internals couldn't even conceive.  Those interfaces haven't
really shown up yet, and I see only the PgAdmin folks even proposing
them.  

> 2) It blocks inserts/updates on the origin. Fixing that would
> require this to algorithm to be integrated deeper into slony itself.

It blocks more than that.  ALTER TABLE blocks everything on the
affected table until transaction COMMIT.  Making that run longer is
exactly what I'm objecting to.

A

-- 
Andrew Sullivan  | ajs at crankycanuck.ca
When my information changes, I alter my conclusions.  What do you do sir?
		--attr. John Maynard Keynes