On June 1, 2007 03:27 pm, Christopher Browne wrote:
> I have noticed a scenario (whilst running DDL tests) which causes me
> to want to add an extra test to the pre-processing of this...
>
> Suppose we have 3 nodes, and subscriptions have been requested for a
> set on all 3 nodes.
>
> Regrettably, due to some error having happened (deranged slon?), the
> third node hasn't yet *successfully* subscribed to the set.
>
> If I restart the slon for node #3, soon enough, all is well, and it
> subscribes successfully.
>
> If a DDL change comes through, before that time, that can (and will)
> destroy the ability to do this.
>
> The DDL change is successfully processed, and hits nodes 1 and 2.
>
> If, at *THAT* point, I restart the slon for node #3, it tries
> processing the original SUBSCRIBE SET event, only to discover that the
> COPY output from the providers (which have taken account of the
> EXECUTE SCRIPT request) have different schemas than node #3.  At which
> point node #3 is screwed.  No reasonable fix possible short of
> toasting it and recreating the node.
>
> I propose to check to have EXECUTE SCRIPT fail if it discovers a
> subscriber from which it does not have a recent confirmation.  (I have
> yet to figure out the exact nature of the sl_confirm query; I'll wait
> 'til Monday on the off-chance that I might get to work and discover a
> solution in my inbox ;-).)

Would the easy answer not be to look to see if the subscribe event has been 
confirmed by all nodes ?




-- 
Darcy Buskermolen
Command Prompt, Inc.
+1.503.667.4564 X 102
http://www.commandprompt.com/
PostgreSQL solutions since 1997