We recently had an issue with a long Slony (2.0) catch-up after 10 days of disconnect between a master and a slave. It&#39;s possible that it was caused by either bug 167 or bug 222. To test this behavior we made a dummy cluster on our local LAN, and did the following steps:<div>

<br></div><div>1. Initialize a two-node Slony cluster with two identical copies of the database. </div><div>2. Allow initial subscription to catch up. </div><div>3. On the slave: drop the network connection to the master.</div>

<div>4. On the master: run ~4 million update operations.</div><div>5. On the slave: restore the connection to the master. </div><div><br></div><div>We did this, and I was able to watch sync events get submitted and received in the logs. However, in sl_status, st_lag_num_events and st_lag_time kept going up, and the backlogged changes were not propagated (after a couple of hours, at least). The LAN link between the two nodes is fast, and neither node is lagging due to server/IO/network load. Why is this occurring/what did I do wrong?</div>

<div><br></div><div>Also, on what time period do you publish RPMs of Slony to public Yum repositories? (i.e. when should we expect to see an RPM of Slony 2.1?)</div><div><br></div><div>Thanks!</div>