On Tue, Dec 12, 2006 at 08:22:35PM +0100, Andreas Kostyrka wrote:
> Ok, so how does the 
> psql -c 'alter table x add column y text;' -h slave
> psql -c 'alter table x add column y text;' -h master
> 
> break? I need to ask as I've been using it for over 6 months without
> troubles.

You do have troubles; you just don't know it.  That's what I keep
trying to impress upon everyone; I don't understand what it is about
"your trigger doesn't know about all your data, and will behave
unpredictably" is failing to set off your alarm bells.

> Well, mysql seems to have "sensible" replication that handles DDLs
> sensibly. Well, that's why PostgreSQL and slony are scheduled here to
> be phased out ;)

Yes, "seems" is the right word there.  No sarcasm on.  It will
possibly work for you, and if so, good.  

> Yes, it's possible to do planned shutdowns. It's just very bothersome,
> and doesn't look to well, when all the other components are being
> optimized for upgrades under load, and I need to kill the DB
> connections to add a field? While I can rollout major upgrades to the
> application without interrupting service?

Your contribution of a design in which DDL can be safely added (for
sure, without breaking all the other safeguards that are built into
Slony as befits an industrial tool) is eagerly awaited.

This was the compromise we came to: either DDL is unsafe and possibly
breaks the application of data, or else we have to lock to prevent
the DDL.  If someone can invent the foot-gun setting that does not
break things for everyone who likes to operate safely, but that
allows people to do things unlocked, I expect that there would be
some interested in it.  Better, if someone can figure out how to
deliver the results in the agreeable order without imposing the locks
we already have, I'd be interested.

So far, all I hear are hand-wavy proposals about how this is all
easy, and suggestions that having triggers on system catalogues would
solve all this for us.  Nobody ever replies to the reasons why that's
false.  If you really have studied MySQL's replication, and think
it's good enough for you, I'm happy to hear it.  My data turns out to
be worth more than my cost-benefit analysis tells me I'll get on
the benefit side, so I'm going to go for the safe system.  That
doesn't mean I don't think this would be a useful feature.  It would
be, and if I could see a way to a safe implementation (like Steve S.
says he's working on), I'll be real interested.

A

-- 
Andrew Sullivan  | ajs at crankycanuck.ca
The plural of anecdote is not data.
		--Roger Brinner