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





--- Comment #2 from Christopher Browne <cbbrowne at ca.afilias.info>  2009-04-01 13:14:00 ---
We oughtn't be heavily vacuuming (or needing to vacuum) sl_log_{1,2} in v2.0
anymore, because part of the logic of the cleanup thread (see pl/pgsql function
logswitch_finish()) involves using TRUNCATE to regularly clear the data out of
the unused partition of the sl_log_* tables.

That's a change new to 2.0...

A couple of thoughts...

1.  You could make sl_log_* "less vacuumed" by removing them from
pg_autovacuum, so that autovac *would* do the vacuuming on them.

As of 2.0, there shouldn't be DELETEs going in (if the Slony-I config value
cleanup_deletelogs is set to FALSE, as is its default), so autovac shouldn't
want to do much work on them.

Note that the Slony-I cleanup thread checks the table pg_autovacuum to see what
tables it shouldn't manage, so deleting sl_log_1/2 from pg_autovacuum would
take effect on Slony-I's behaviour immediately.

This is a little counterintuitive...  You may get better behaviour by having
the log tables be handled by autovac :-).

2.  The apparent trouble is that logswitch_finish() isn't running TRUNCATE on
sl_log_2.

You can run logswitch_finish directly; one of the changes in 2.0 was to take
the logic that had been pretty tightly embedded into C code in cleanup_thread.c
and factored it out into the pl/pgsql code.

select _myschema.logswitch_finish();

should raise some notifications indicating what work it's doing.

"Belt & suspenders" would suggest prefixing it with a BEGIN; to stick it in a
transaction so that if there *was* some unexpected result, you could roll it
back ;-).

But it should be pretty safe...


-- 
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.