On Wed, Jul 02, 2008 at 04:14:51PM +0200, Csaba Nagy wrote:
> 
> But that's a lot messier and riskier than having a script with a few
> clear instructions in what circumstances it can work, and maybe a few
> checks to enforce those circumstances are met (e.g. it must be a way to
> figure out in a programmatic way if there are any FKs to/from that
> table). It would also be relatively easy to enforce that the SQL to be
> applied is just 1 statement which only touches 1 table...

That's the arrangement we used to have, and it didn't work.  It's how the
lock got as heavy duty as it is.

>  - keep watching my DBs for the moment I can sneak in a full DB lock
> without breaking too many things (we managed to grow ourselves to the
> point we have a pretty round the clock operation which is really always
> busy);

If you can't schedule 10 minutes of downtime for a schema change, then
Slony's the wrong tool for your job.  Sorry.  It can't provide five-nines.
 
>  - study the bare metal functions you're talking about and cross my
> fingers it wont kill my DB;
> 
> Both of these alternatives are very uncomfortable to me. Any script
> which gets some testing would be a lot safer and welcome...

The script will get more testing for your environment if you write it for
your environment.  A general-purpose script isn't ever going to get enough
testing.  And you don't have to cross your fingers: those functions _get
called all the time_.  They're what Slony uses. 

You really have two choices, but they're not the ones you listed:

1.  Live with the Slony-provided limitation.

2.  Become expert in Slony, and then write something that reduces the locks
taken while still behaving safely in your environment.

If you want all of fast, cheap, and good, you're not going to get it.  Sorry
:-(

A