http://www.slony.info/bugzilla/show_bug.cgi?id=128

--- Comment #1 from Christopher Browne <cbbrowne at ca.afilias.info> 2010-08-19 12:55:15 PDT ---
That seems pretty apropos to me.

There's still a problem can take place on a remote node...

Suppose the sequence of events is thus:

1.  Table gets dropped on several nodes, possibly not the origin.

2.  MOVE SET is submitted, and, as the table was there on the origin, works
fine, and starts propagating.

3.  SET DROP TABLE is submitted.

The MOVE SET can keep on failing on the subscriber due to the table being gone.
 It'll never get around to the SET DROP TABLE request.

A resolution to this scenario would be for MOVE SET to have an exception block
that catches the "table not found" problem, and then peeks into the future
event stream to see if a suitable SET DROP TABLE is waiting.

It could, still, of course, be a terrible idea to do this.  

Note that a similar problem can happen with plain SYNCs, with some sl_log_[1|2]
entries getting "orphaned" because the table got dropped a subscriber before
relevant sl_log_* data got drained out.

The two problems likely need similarly shaped resolutions.

-- 
Configure bugmail: http://www.slony.info/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.