On 6/1/2007 6: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 ;-).)

"... a recent confirmation" ???

If you really want to guard against this stupidity, abort all DDL script 
execution if there are ANY unconfirmed subscriptions in the system. And 
that is not the SUBSCRIBE_SET event alone, but the ENABLE_SUBSCRIPTION too.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #