Brad Nicholson <bnichols at ca.afilias.info> writes:
>  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.

Here are a couple approaches to specify the locking, which includes, I
think, what you suggest:

  3.  An extra parameter to EXECUTE SCRIPT is a quoted comma-separated
      list of the IDs (as in sl_table.tab_id) of tables to be locked.

      execute script (set id=1, filename='/tmp/ddl-script.sql',
                      event node=3, tables to lock='1,2,17,29,35');

      While this is somewhat nice in the sense that we can validate (and
      raise errors, if invalid) that the tables being locked are
      legitimate ones, the table IDs aren't the most obvious thing in
      the world to look up.

  4.  An extra parameter to EXECUTE SCRIPT indicates the filename of
      a file containing the LOCK TABLE requests.

      execute script (set id=1, filename='/tmp/ddl-script.sql', 
                      event node=3, lockfile='/tmp/locks.sql');

      I think this is more or less what you're suggesting, and it seems
      fine to me.  

I think I like "#4" the best of any of the options, thus far.  I'm not
sure Jan/Steve have seen them, so it's premature to treat it as
"decided."

>> 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.

I'm pretty ok with *that* "magic behaviour" (e.g. - "specify nothing,
and Slony will lock everything.")
-- 
select 'cbbrowne' || '@' || 'ca.afilias.info';
Christopher Browne
"Bother,"  said Pooh,  "Eeyore, ready  two photon  torpedoes  and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"