"James Tucker" <jameshtucker at gmail.com> writes:
> Hi All,
> One of our applications has had an issue and queued up a massive amount of updates to a table containing huge binary columns.  We don't actually
> care about any of these updates and have removed everything from the table on the master, however the slave still has a large number of events
> queued up to process.  Because of a few constraints it simply can't keep up and is just falling further and further behind.
> Can I simply remove the offending updates from the sl_log table on the master ?

There is something of "rocket surgery" to this, but yes, you could
identify and remove offending updates from the sl_log_? table on the
master.

I'd want to carefully identify the table, and be really certain that I
had it right before getting to a COMMIT statement :-).

] begin;
] select count(*) from _my_schema.sl_log_1 where log_tableid = 42;
[make sure that reported an apropos number of tuples for the table I think is #42...]
] delete from _my_schema.sl_log_1 where log_tableid = 42;
[make sure that reports something consistent with what is expected...]
] commit;
-- 
select 'cbbrowne' || '@' || 'linuxfinances.info';
http://cbbrowne.com/info/slony.html
Rules  of the  Evil Overlord  #145. "My  dungeon cell  decor  will not
feature exposed pipes.  While they add to the  gloomy atmosphere, they
are good  conductors of vibrations and  a lot of  prisoners know Morse
code." <http://www.eviloverlord.com/>