Re: [HACKERS] md.c is feeling much better now, thank you

Vadim Mikheev <vadim(at)krs(dot)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