> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Friday, September 03, 1999 8:03 AM
> To: Vadim Mikheev
> Cc: Hiroshi Inoue; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] md.c is feeling much better now, thank you
>
>
> 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.
>
How about inserting "RelationDecrementReferenceCount(relation);"
between LockAcquire() and DiscardInvalid() ?
And isn't it preferable that LockRelation() returns the relation
which RelationIdGetRelation(tag.relId) returns ?
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp