Rudder

Indeed, VACUUM FULL is frowned upon if it's not done outside on maintenance windows ( http://serverfault.com/questions/264221/postgresql-8-4-auto-vacuum-is-enabled-to-get-the-best-performance last answer) for it locks the database.
Erasing gigs of data inside a table can be a very long process (in terms of dozens of minutes), effectively blocking the whole application (and log collection)

The archived reports can be, I feel, safely vacuum fulled, it would prevent other archiving during this time, and people could leave with it

Setting a temporary table would probably not solve the issue, and would have too much impact to allow the release of Rudder 2.4 in November (it would impact log collection and reporting)

Yes for temporary table, I was just keeping a track about that idea to explore in a following version (2.5).

I'm ok with the idea of having a vacuum full only on the archived reports, it should not be a problem

François ARMAND wrote:

The chosen solution is:

- before each cleaning, check if a full vaccuum is currently running, and if so, fail the cleaning, adding a log message (and an error message for the user if the clean request was interactive) explaining why the cleaning can not occures at that time.

I've looked in the Postgres documentation and forum, there doesn't seems to be an easy way to know if a vacuum is in progress. Here there might be something that could be an inspiration on how to do it: http://pgsql.inb4.se/2009/february/follow-up-vacuum-full-progress.html

Since targent branch has changed, I had to make another pull request, technical review can be done here https://github.com/Normation/rudder/pull/8

I have no idea why this ticket is in rudder-doc, and I can't change its project