Mon Feb 18 11:43:19 PST 2008
- Previous message: [Slony1-general] logswitch and deleting entries in the other log table
- Next message: [Slony1-general] proper procedure for re-starting slony after replication slave reboots
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ow Mun Heng <Ow.Mun.Heng at wdc.com> writes: > I learned how to manually force a logswitch. Then I wait, and wait for > the delete to kick in so that my original log_* table gets the contents > deleted. > > What's the algo behind this cleanup anyway? It's in the code; generally, we consider switching logs if that seems practical. (If we are still processing a previous log switch, then it ISN'T practical ;-)!) It gets handled in the fairly asynchronous fashion so that we can be pretty sure that it is safe to TRUNCATE the empty table, and don't need to worry about that TRUNCATE causing other things to block. This bit us, occasionally, with the predecessor eRServer system. It was not as careful about it's approach to using TRUNCATE, and that would sometimes lead to application outages when a log table would be locked by the TRUNCATE :-(. -- select 'cbbrowne' || '@' || 'linuxfinances.info'; http://cbbrowne.com/info/lisp.html Space Corps Directive #997: Work done by an officer's doppleganger in a parallel universe cannot be claimed as overtime. -- Red Dwarf
- Previous message: [Slony1-general] logswitch and deleting entries in the other log table
- Next message: [Slony1-general] proper procedure for re-starting slony after replication slave reboots
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list