Re: relcache refcount

On Fri, May 14, 2004 at 11:21:42PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> > Ok, I created a function to copy a hash table (from dynahash). So now
> > at subtransaction start the RelationIdCache and RelationSysNameCache
> > hash tables are copied, and if the subtransaction aborts the previous
> > hash tables are restored.
>
> I don't think that will do; what about updates absorbed during the
> subtrans from other backends' changes? In any case, copying the whole
> cache state during every subtrans start is not the kind of overhead
> I wish to pay ...

Oh, I see that now. (And I agree with the overhead argument anyway.) I
think I can add a "refcount stack" to RelationData, and update it each
time a subtransaction is entered; on abort, previous counts are restored
for all relations. This is certainly much cheaper than saving the whole
hash, and it is more correct regarding invalidations.

I'll leave the hash_copy() function though ... maybe someone can think
on a use for it ...

I just did something like the refcount stack for the CatCache code. I'm
not sure how to verify that it actually works ... will play with gdb.

> > Regarding the lock mechanism, I simply added some code to LockReleaseAll
> > so it gets the array of committed child Xids; on subtransaction abort,
> > the whole lock struct is scanned just like it's done on main transaction
> > abort; only those locks affiliated with one of the given Xids are
> > released. This is naive, so if it's incorrect please comment.
>
> Not sure; it's been a long day and I'm tired ... will think about it
> tomorrow ...

The kind of issue I am concerned with is what happens when a
subtransaction upgrades a previously acquired lock. Does this release
the lesser lock? I don't think so.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"The first of April is the day we remember what we are
the other 364 days of the year" (Mark Twain)