191271 2007-09-04 17:12 0000 mail-filter/dspam-3.8.0-r4: Calls to vacuumdb in /etc/cron.daily/dspam.cron are redundant. 2007-09-10 04:07:02 0000 1 1 1 Unclassified Gentoo Linux Applications unspecified All Linux RESOLVED FIXED P2 minor --- 1 manuel@mclure.org mrness@gentoo.org manuel@mclure.org 2007-09-04 17:12:55 0000 If dspam is configured using the postgresql back end, dspam.cron runs the pgsql_purge.sql script, and then runs vacuumdb on all affected tables. However, the last line in pgsql_purge.sql is "VACUUM ANALYZE;" which means that the complete database will be vacuumed anyway - the calls to vacuumdb are redundant. mrness@gentoo.org 2007-09-09 20:33:50 0000 Fixed in -r5 by removing vacuum command from pgsql_objects.sql. It might seem the wrong way of fixing it, but I prefer doing things in a consistent manner and cron script is the one who optimize the databases (see mysql and sqlite cleaning procedures). manuel@mclure.org 2007-09-10 03:44:47 0000 OK. There's still a problem in that the script is using "vacuum -f" which does the equivalent of a VACUUM FULL. This is unnecessary on a highly updated table since the space freed up by a plain VACUUM will be reused. Also, a VACUUM FULL puts a lock on the whole table, which means that all dspam requests will fail during the vacuum. Per the PostgreSQL docs: "The FULL option is not recommended for routine use, but may be useful in special cases." Also, if an administrator has configured their PostgreSQL server to include vacuum delays so that a running vacuum has less effect on running queries, this means that the dspam tables may be unavailable for hours on a large database (this is my case.) Do you want me to enter a new bug for this? mrness@gentoo.org 2007-09-10 04:07:02 0000 Fixed in -r6 by running vacuumdb -z instead -f.