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

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Friday, September 03, 1999 8:03 AM
> To: Vadim Mikheev
> Cc: Hiroshi Inoue; pgsql-hackers(at)postgresql(dot)org
> Subject: 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.
>

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(at)tpf(dot)co(dot)jp