Re: [HACKERS] md.c is feeling much better now, thank you - Mailing list pgsql-hackers

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