On Wed, Mar 2, 2011 at 10:15 AM, Steve Singer <ssinger at ca.afilias.info> wrote:
>
> Consider this:
>
> subscribe set(id=1,provider=1,receiver=2);
> EXECUTE SCRIPT(set id=1,
> FILENAME='/tmp/some_add_column_script.sql',event node=1);
>
> If the execute script  is submitted on node 1 before the COPY_SET on
> node 2 (copying the data from node 1) takes place the copy will pull the
> new column but that column won't yet exist on node 2 since the execute
> script won't get processed on node 2 until after the subscribe.
>
> Any of the following should address this
>
> 1) When submitting an EXECUTE SCRIPT slonik will require all nodes to be
> 'caught up'.
>
> 2) When submitting an execute script slonik will wait until all pending
> subscriptions be active (all sets, all nodes involved in any part of the
> execute script)
>
> 3) When submitting an execute script slonik will require all pending
> subscriptions to be active for the set id specified on the execute
> script command line.
>
> I don't like 3 because often a single SQL script will need to involve
> tables from multiple sets, the 'set id' on execute script probably
> should be removed (in old versions of slony this controlled locking but
> it turned out to be not good enough, probably for the same reason)
>
> I am inclined to go with 1, because it is easier to implement than 2.
> Thoughts?

I agree that 3 isn't very good, because the locking control turns out unhappily.
It seems easier to fail, with a good error message, than to wait,
making things seem more "magical."