Steven Flatt wrote:
The bad thing, which I don't totally understand from reading the docs, is that another db-wide vacuum kicked off exactly 24 hours after the first db-wide vacuum kicked off, before the first one had finished. (Note that these vacuums seem to go through the tables alphabetically.) I managed to explain this to myself in that there were still rows in tables not yet touched by the first db-wide vacuum that could have XIDs older than autovacuum_freeze_max_age. Fine, so two db-wide vacuums were now taking place, one behind the other.
Are you sure there's no cron job starting the vacuums? 24h sounds too good to be a coincidence, and there's no magic constant of 24h in the autovacuum code. Besides, autovacuum can only be running one VACUUM at a time, so there must be something else launching them.
What's your vacuuming strategy in general, before and after upgrade? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
