Thread: CatCache state reversing

Hackers,

In looking at the CatCache code it's clear to me that there's no point
in copying the whole structure like I did to the Relcache; it's much
bigger, and there's not much that can change inside a subtransaction:
CatCacheRemoveCTup can't be called, because ReleaseCatCache will not be
called more times than SearchCatCache was called.  So it can, at most,
end with the same number of references.

What I'm currently thinking is that for each entry in the cache, we'll
save the current refcount at subtransaction start, and then restore it
at subtransaction abort.  At subtransaction commit, the parent's
refcount will be updated with the subtransaction's refcount, which can
be greater than zero.

This will be done by adding an int* member to the catctup and catclist
structs, and keeping the integers there.

Comments?

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"People get annoyed when you try to debug them."  (Larry Wall)

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> What I'm currently thinking is that for each entry in the cache, we'll
> save the current refcount at subtransaction start, and then restore it
> at subtransaction abort.  At subtransaction commit, the parent's
> refcount will be updated with the subtransaction's refcount, which can
> be greater than zero.

No it can't.  The reference counts should all be exactly the same at
subtrans start and subtrans commit, else there was a reference leak.
This corresponds to complaining if the count isn't zero at main trans
commit.  I don't see that there should ever be a situation where a
subtrans releases a refcount acquired by an outer trans or vice versa.

While you're looking at that, what about the cache invalidation logic?
I think subtrans commit is probably not different from
CommandCounterIncrement, but I'm not sure how to clean up the caches and
the pending-inval lists on subtrans abort.
        regards, tom lane