Apologies if this is old news, but pg_autovacuum in 8.0.x has the bad habit of SEGVing and exiting when a table gets dropped out from under it. This creates problems if you rely on pg_autovacuum for the bulk of your vacuuming as it forgets it's statistics when it is restarted and so will skip some desireable vacuums. I looked at the new autovacuum in 8.1 and it appears from casual inspection not to have the same problem.
Below is a patch for this that should apply against any 8.0.x. The change verifies that the catalog query returned some rows before accessing the row data. -dg diff -Naur source/postgresql-8.0.2/contrib/pg_autovacuum/pg_autovacuum.c build/postgresql-8.0.2/contrib/pg_autovacuum/pg_autovacuum.c --- source/postgresql-8.0.2/contrib/pg_autovacuum/pg_autovacuum.c 2005-04-02 16:02:03.000000000 -0800 +++ build/postgresql-8.0.2/contrib/pg_autovacuum/pg_autovacuum.c 2005-09-28 22:15:25.428710172 -0700 @@ -1013,6 +1013,7 @@ static void perform_maintenance_command(db_info * dbi, tbl_info * tbl, int operation) { + PGresult *res; char buf[256]; /* @@ -1069,10 +1070,16 @@ fflush(LOGOUTPUT); } - send_query(buf, dbi); - - update_table_thresholds(dbi, tbl, operation); - + res = send_query(buf, dbi); + if (PQntuples(res)) { + update_table_thresholds(dbi, tbl, operation); + } else { + if (args->debug >= 1) { + sprintf(logbuffer, "Cannot refind table %s", tbl->table_name); + log_entry(logbuffer, LVL_DEBUG); + fflush(LOGOUTPUT); + } + } if (args->debug >= 2) print_table_info(tbl); } -- David Gould [EMAIL PROTECTED] If simplicity worked, the world would be overrun with insects. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend