Hello,

I'm working on a fairly substantial database with several large tables
(seven orders of magnitude each) replicated.  For the sake of this
description, consider one database master and one slave where table B
references table A with ON DELETE CASCADE specified.  In the course of a
normal day, say 100,000 records are INSERTed/UPDATEd and 90,000 records
are DELETEd from A.  Replication typically works without issue.

Recently, we executed DELETE FROM A WHERE ... on the master.  As
expected, this purged nearly 75% of the recordsets in tables A and B.
Our slave has been unable to maintain synchronization.  The system
completes a nightly VACUUM ANALYZE job on all objects -- this has been
disabled from before the massive DELETE.  Taking the advice of this
list, we attempted a REINDEX of sl_log_1/2, which was unable to complete
without disrupting other services -- eventually the REINDEX was killed.
 sl_log_1/2 currently have 0 and 50M records, respectively; and,
sl_log_2 is growing.

Our current theory is that sl_log_1/2 have become unreasonably
large/bloated.  Our slaves initiate FETCH 100 FROM LOG that execute for
30+ minutes and must occasionally be canceled to prevent service
disruptions.

As tables A and B no longer require replication, we wish to disable
replication of those tables and purge the queued events for those
tables.  To do this, can we do something akin to the following?

1. Disable Slony on both master and slave,

2. Reconfigure Slony to not replicate A or B,

3. On the master: DELETE FROM sl_log_1/2 WHERE sl_table = # AND
log_cmdtype = 'D'

4. On the master: VACUUM FULL ANALYZE sl_log_1/2, REINDEX TABLE
sl_log_1/2, ANALYZE sl_log_1/2,

5. Re-enable replication, and

6. On the slave: DELETE FROM A, VACUUM FULL ANALYZE A/B.

We currently run Linux v2.6.18, PostgreSQL v8.1.4, and Slony-I v1.2.2 on
both master and slave.

Thank you in advance to any assistance you can provide,

-Andrew