Bugzilla Bug 191271

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.

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

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?

Fixed in -r6 by running vacuumdb -z instead -f.