Vadim Mikheev <vadim@krs.ru> writes:
> Tom Lane wrote:
>> My guess is that we ought to be checking for relcache invalidation
>> immediately after gaining any lock on the relation. I don't know where
>> that should be done, however.
> Seems as GOOD solution!
> We could do inval check in LockRelation() just after LockAcquire().
I tried inserting code like this in LockRelation:
--- 163,176 ---- tag.objId.blkno = InvalidBlockNumber;
LockAcquire(LockTableId, &tag, lockmode);
!
! /* Check to make sure the relcache entry hasn't been invalidated
! * while we were waiting to lock it.
! */
! DiscardInvalid();
! if (relation != RelationIdGetRelation(tag.relId))
! elog(ERROR, "LockRelation: relation %u deleted while waiting to
lock it",
! tag.relId); }
/*
and moving the smgrclose() call in RelationFlushRelation so that it is
called unconditionally.
Doesn't work though: the ALTER TABLE tests in regress/misc fail.
Apparently, this change causes the sinval report from update of the
relation's pg_class heap entry to be read while the relation has refcnt>0,
so RelationFlushRelation doesn't flush it, so we have an obsolete
relation cache entry. Ooops.
Did you have a different approach in mind? Or do we need to redesign
RelationFlushRelation so that it rebuilds the relcache entry, rather
than dropping it, if refcnt > 0?
regards, tom lane