Yup, that's true -- when you issue EXECUTE SCRIPT, it locks every table
in the set.

We've found that even if the locking imposed by Slony didn't exist,
there's still some other locking we can't avoid.  E.g. when you issue
any kind of alter table statement, it locks the table (we use Postgres;
your results may vary).  That alone is bad enough that we don't want to
do schema changes while the site is live, so we generally have short
site-down times to perform schema changes.  If your schema changes are
too frequent to deal with all these site down times, you might want to
consider a less strongly typed schema.

By the way, several times now we've taken the approach of switching
master DB's when we have significant schema changes to make.  The
general process is:
1. Get a slave up-to-date
2. Stop all access to the master DB so that the data there doesn't
change anymore
3. Remove the slave from replication
4. Run your schema changes on the slave
5. Reconfigure the apps to use this slave as the new master and start
them up again.
6. Re-initialize replication from the new master to the other nodes.

Note: this approach doesn't involve EXECUTE SCRIPT at all.

The nice thing about this approach is that there's a pretty simple
fallback mechanism -- the old master DB is still there, unchanged, in
case you need it.  The flip side is that it requires downtime and that
for the first while after the release you're running on a master with no
slaves.  That may or may not be acceptable in your situation.

--S


-----Original Message-----
From: slony1-general-bounces at lists.slony.info
[mailto:slony1-general-bounces at lists.slony.info] On Behalf Of Adam Olsen
Sent: Tuesday, August 19, 2008 10:00 AM
Cc: slony1-general at lists.slony.info
Subject: Re: [Slony1-general] Help with grouping sets

The issues described in section 7.2 here:
http://slony.info/documentation/definingsets.html

The most concerning one is the one regarding "EXECUTE SCRIPT", as, in
the beginning our schema might change somewhat frequently.

Adam

On Tue, Aug 19, 2008 at 10:56 AM, Shahaf Abileah <shahaf at redfin.com>
wrote:
> What deadlocking issues?
>
> We have about 100 tables in a single set and things are working out
> pretty well.
>
> Note: not all of our 100 tables are related to one another via foreign
> keys; we chose to keep everything in a single set purely for
simplicity.
>
> --S
>
> -----Original Message-----
> From: slony1-general-bounces at lists.slony.info
> [mailto:slony1-general-bounces at lists.slony.info] On Behalf Of Adam
Olsen
> Sent: Tuesday, August 19, 2008 9:32 AM
> To: slony1-general at lists.slony.info
> Subject: [Slony1-general] Help with grouping sets
>
> Hello,
>
> First off, I'm sorry if this seems like a stupid question.
>
> I'm trying to group my tables into sets.  In the online documentation,
> it says that "It will be vital to group tables together into a single
> set if those tables are related via foreign key constraints".  I am
> creating a Django application, and every table is related to some
> other table via a foreign key.  Sometimes this relation is to the
> "User" table, and sometimes this relation is to a table that has a
> relation to the "User" table.  We don't have any tables that aren't
> somehow associated to the "User" table.
>
> We have quite a few tables, so this means that, to my understanding,
> all of our tables need to be in a single set.  From what I understand,
> this can cause deadlocking issues, and I'd obviously rather avoid
> that.
>
> What can I do to better group my sets?
>
> --
> Adam Olsen
> SendOutCards.com
> http://www.vimtips.org
> http://last.fm/user/synic
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
>
>
>



-- 
Adam Olsen
SendOutCards.com
http://www.vimtips.org
http://last.fm/user/synic
_______________________________________________
Slony1-general mailing list
Slony1-general at lists.slony.info
http://lists.slony.info/mailman/listinfo/slony1-general