Fix old bug in log_autovacuum_min_duration code: it was relying on being able
authorTom Lane <[email protected]>
Wed, 12 Aug 2009 18:23:49 +0000 (18:23 +0000)
committerTom Lane <[email protected]>
Wed, 12 Aug 2009 18:23:49 +0000 (18:23 +0000)
to access a Relation entry it had just closed.  I happened to be testing with
CLOBBER_CACHE_ALWAYS, which made this a guaranteed core dump (at least on
machines where sprintf %s isn't forgiving of a NULL pointer).  It's probably
quite unlikely that it would fail in the field, but a bug is a bug.  Fix by
moving the relation_close call down past the logging action.

src/backend/commands/analyze.c

index 5d6f32f708b7a3e1923443372653957dcc001b2a..71db483565da4326c6140b67b30ceeadea5b442a 100644 (file)
@@ -518,14 +518,6 @@ cleanup:
        /* Done with indexes */
        vac_close_indexes(nindexes, Irel, NoLock);
 
-       /*
-        * Close source relation now, but keep lock so that no one deletes it
-        * before we commit.  (If someone did, they'd fail to clean up the entries
-        * we made in pg_statistic.  Also, releasing the lock before commit would
-        * expose us to concurrent-update failures in update_attstats.)
-        */
-       relation_close(onerel, NoLock);
-
        /* Log the action if appropriate */
        if (IsAutoVacuumWorkerProcess() && Log_autovacuum_min_duration >= 0)
        {
@@ -540,6 +532,14 @@ cleanup:
                                                        pg_rusage_show(&ru0))));
        }
 
+       /*
+        * Close source relation now, but keep lock so that no one deletes it
+        * before we commit.  (If someone did, they'd fail to clean up the entries
+        * we made in pg_statistic.  Also, releasing the lock before commit would
+        * expose us to concurrent-update failures in update_attstats.)
+        */
+       relation_close(onerel, NoLock);
+
        /*
         * Reset my PGPROC flag.  Note: we need this here, and not in vacuum_rel,
         * because the vacuum flag is cleared by the end-of-xact code.