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

> -----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