Looks reasonable to me. All the patch does is make sure that the result set is valid. Probably a check I should have done from the beginning, or pg _autovacuum should be locking tables to make sure they aren't dropped, but that sounds too intrusive, this is probably better.


daveg wrote:
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


diff -Naur source/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 @@
- 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", 
+                       log_entry(logbuffer, LVL_DEBUG);
+                       fflush(LOGOUTPUT);
+               }
+       }
        if (args->debug >= 2)

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to