> On 3/21/07, Warren Little <warren.little at meridiascapital.com> wrote:
>
>> Also, is there a guide to configuring Slony-I on an active system, or is
>> the
>> procedure the same (aside for the standard "backup all data before you
>> begin")
>
> You may want to schedule a brief maintenance window when initially
> adding tables since it requires an exclusive lock. Which is part of
> the standard procedures, however I thought I'd mention it specifically
> to make sure you don't miss it.

There's a difference between the locking for this and other locking; the
SET ADD TABLE action requires a brief exclusive lock to attach the
replication trigger to each table.

Unlike behaviour on subscribers, where there winds up being one grand
transaction requiring exclusive locks on ALL the replicated tables, all at
once, the actions initially on the master are (hopefully) brief, and go
individually, table by table.

If you have processes on the master database that hold lots of locks, this
can bite you.  If you don't have heavy locking going on there, SET ADD
TABLE may be able to slip through fairly trouble-free alongside the other
traffic.

We've frequently been able to add new tables (not yet used by the
application) on the fly while application users are connected.  Tables
that are thus far unused will be pretty easy on locking.  It's less clear
what'll happen with busy tables that are widely used.

In such a case, it's entirely possible for there to be a few seconds of
pause as the request for the exclusive lock blocks everything that comes
in behind it, but still has to wait until all the requests that came in
before it clear their way through.  Whether that's milliseconds or seconds
or more depends on the usage pattern...