Fix old bug in log_autovacuum_min_duration code: it was relying on being able

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.
This commit is contained in:
Tom Lane 2009-08-12 18:23:49 +00:00
parent 9d9848668f
commit a1f0c9bab9

View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/commands/analyze.c,v 1.140 2009/08/02 22:14:52 tgl Exp $
* $PostgreSQL: pgsql/src/backend/commands/analyze.c,v 1.141 2009/08/12 18:23:49 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -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.