I responded to I think most of your points in the other email, but
there is one thing:

On 3 January 2012 17:33, Christopher Browne <cbbrowne at afilias.info> wrote:
> On Tue, Jan 3, 2012 at 5:49 AM, Martijn van Oosterhout
> <kleptog at gmail.com> wrote:
>> In any case, the way we fixed it before was to unsubscribe and
>> resubscribe the set, because resyncing the whole database is quicker
>> than waiting for the deletes to complete. However, this time it broke
>> in a new way. The result is that slony thinks it is properly
>> subscribed, but the database data has not been resynced, so you get
>> some bastard combination of old and new data. Logs below.
>
> Unfortunately, the UNSUBSCRIBE request comes in as an event, and it's
> later in the event stream than the SYNC-of-the-million-deletes, so
> it's probably not processing when you think it ought to.

In our experience whenever the replication is behind, doing an
unsubscribe is acted upon immediately. I always thought this was by
design, though I couldn't work out why. But you're saying it shouldn't
work at all... That's just weird.

I'll have to pay more attention next time to see exactly what happened.

Have a nice day,
-- 
Martijn van Oosterhout <kleptog at gmail.com> http://svana.org/kleptog/