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:55 +00:00
parent f85de25433
commit 3dc494f0a3

View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/commands/analyze.c,v 1.139 2009/06/11 14:48:55 momjian Exp $
* $PostgreSQL: pgsql/src/backend/commands/analyze.c,v 1.139.2.1 2009/08/12 18:23:55 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -513,14 +513,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)
{
@ -535,6 +527,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.