Re: 7.2.3 vacuum bug

Rod Taylor <rbt(at)rbt(dot)ca> writes:
> ERROR: RelationClearRelation: relation 11584078 deleted while still in
> use

> I've been unable to come up with a test case that will cause the
> problem, seems to be timing related. The queries that are currently
> running when these errors occur do a lot or work with temp tables that
> are frequently truncated.

Hm. vacuum.c tries to avoid this class of problem:

/*
* Race condition -- if the pg_class tuple has gone away since the
* last time we saw it, we don't need to vacuum it.
*/
if (!SearchSysCacheExists(RELOID,
ObjectIdGetDatum(relid),
0, 0, 0))
{
CommitTransactionCommand(true);
return true; /* okay 'cause no data there */
}

...

onerel = relation_open(relid, lmode);

but on reflection it's clear that this doesn't really prevent a race
condition. If the table is already exclusive-locked by a DROP TABLE
that hasn't committed yet (eg, the implicit DROP that happens when temp
tables are cleared out at backend exit), then the syscache lookup will
go fine, but the relation_open() routine blocks waiting for lock and
eventually fails.

What would probably work better is to first lock the relation OID,
then see if we can open the relation or not.

Thinking further, it's really kinda bogus that LockRelation() works on
an already-opened Relation; if possible we should acquire the lock
before attempting to create a relcache entry. (We only need to know the
OID and the relisshared status before we can make a locktag, so it'd be
possible to acquire the lock using only the contents of the pg_class row.)
Not sure how much code restructuring might be involved to make this
happen, but it'd be worth thinking about for 7.4.

regards, tom lane