Bug 120 - store path - after slon has started does not take effect
Summary: store path - after slon has started does not take effect
Status: RESOLVED FIXED
Alias: None
Product: Slony-I
Classification: Unclassified
Component: slon (show other bugs)
Version: 2.0
Hardware: All All
: high minor
Assignee: Steve Singer
URL:
Depends on:
Blocks:
 
Reported: 2010-05-12 12:27 UTC by Steve Singer
Modified: 2010-08-11 14:04 UTC (History)
1 user (show)

See Also:


Attachments
patch for bug 120 (7.64 KB, patch)
2010-06-29 06:02 UTC, Steve Singer
Details
new patch (1.84 KB, patch)
2010-07-09 11:20 UTC, Steve Singer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Singer 2010-05-12 12:27:28 UTC
Create a cluster and start up the slon processes for each node, do not define any paths.

Now add some paths with 'store path(....)' via slonik.

Do NOT restart the slon processes, but do things that require using the paths (ie subscribe a set).   Replication does not seem to happen, it seems that the slon process won't see the path until it restarts.
Comment 1 Steve Singer 2010-06-28 13:49:59 UTC
This problem has been observed following a CLONE PREPARE/CLONE FINISH.

If you add paths between the new node and providers nothing happens.
The issue seems to be that in slon the no_active attribute of the node structure is initialized to false in rtcfg_storeNode.

The only places this is attribute is set to true are
1) On startup in SlonMain based on the value in sl_node
2) In response to an ENABLE_NODE event.

I think the STORE_NODE event processing code should check the current status of sl_node to determine if the node is enabled or not.
Comment 2 Steve Singer 2010-06-29 06:02:32 UTC
Created attachment 45 [details]
patch for bug 120
Comment 3 Steve Singer 2010-07-09 11:20:33 UTC
Created attachment 47 [details]
new patch

This patch replaces the previous patch.
It directly addresses the CLONE NODE issue without having to change other parts of the code
Comment 4 Christopher Browne 2010-08-11 12:28:53 UTC
Seems apropos to me.
Comment 5 Steve Singer 2010-08-11 14:04:19 UTC
This has been committed to master + REL_2_0_STABLE
66635a8138d6010024834a2416ee63337d366f69
0d1a293927805e5728c39f8000031bd698ab49c4