"Victoria Parsons" <[EMAIL PROTECTED]> writes: > We have found we need to perform this vacuum full on pg_listener once > every 10 minutes, instead of once an hour, but doing that our > performance problem is fixed. I am a bit worried about locks, but my > test system has now been running with the vacuum full (only on > pg_listener) every 2 minutes for 3 days, and nothing has reported an > error. A block causing a slight delay is much better than a constant > performance problem.
I don't see this being a particularly "awful" application of VACUUM FULL. VACUUM FULL on pg_listener will cause a bit of deferral of replication activity, but what's good is that pg_listener _isn't_ accessed by the triggers that are put on the tables, so the REALLY VITAL concern, namely that we don't want to stop the user's application, is met. This VACUUM FULL doesn't prevent the user's application from modifying the application tables and seeing those updates get queued in sl_log_[12]. I daresay that in my tenure in DB Operations, I have *never* scheduled a VACUUM FULL of any table (outside of maybe a situation of doing so by hand during an outage). Certainly I've never scheduled VACUUM FULL in a cron... But on the other hand, I do not see a reason to be overly paranoid about doing so to the table pg_catalog.pg_listener. -- (format nil "[EMAIL PROTECTED]" "cbbrowne" "ca.afilias.info") <http://dba2.int.libertyrms.com/> Christopher Browne (416) 673-4124 (land) _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
