On 10-08-19 02:58 PM, Christopher Browne wrote:
> Actually, that suggests to me a *bit* more sophisticated semantics...
>
> EXECUTE SCRIPT works two ways:
>
>    1.  If the DDL begins with LOCK statements, then EXECUTE SCRIPT begins
>    by locking those tables specified in the LOCK statements.
>
>    2.  If the DDL begins without any LOCK statements, then EXECUTE SCRIPT
>    assumes that *ALL* tables should be locked.
>

+1 on the idea, -1 on the implementation.  I've never been a fan of 
magic values that implicitly takes a different code path based on the 
values detected like this.

I would much rather see an extra parameter added to the EXECUTE SCRIPT  
where you could specify a separate file containing the locks.  If you 
provide it, Slony uses those, if you don't, it uses it's default 
locking.  I think this is cleaner from the users perspective.
> Thus:
>
>   - If you're a smart DBA, who knows what tables need to be locked, you
>     can specify them, as in case #1, leaving other tables unlocked, so
>     concurrent updates can continue unabated.
>
>   - If you didn't know what to lock, and didn't bother lock anything,
>     Slony-I protects the data from error by automatically demanding locks
>     on all the tables.
>
> I'd be uncomfortable with the default being to "lock nothing," which
> *could* be an option #3.

Agreed - default of lock nothing is really bad and will end up with lots 
of people breaking their replication sets.


-- 
Brad Nicholson  416-673-4106
Database Administrator, Afilias Canada Corp.