Re: relcache refcount

On Thu, May 13, 2004 at 09:43:42AM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> > I'm stuck trying to figure out how to decrease reference counting for
> > relcache entries at subtransaction abort.
>
> > Initially I thought I could just drop them all to zero,
>
> Nope, you can't. An active query plan will surely have open relations.

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. It seems to do the right thing (i.e. at main
transaction commit the refcounts seem to be OK, which was not true in my
previous tests). I would like a comment on this solution.

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. It seems
to work OK on the simple tests I did.

Incidentally, I noted that the relcache refcounts were wrong while
testing deadlock handling; there were unreleased relcache messages from
the aborted subtransaction. Those are now gone, as expected.

I'm still missing a solution for Catcache and the buffer manager, but
I'd like review on what's currently done. I'll post the current patch
to patches shortly.

PS: Either the list server is getting very slow or it has started to
lose mail. I asked yesterday whether it was OK to copy the hash but
apparently the mail didn't make it to the list. Is there something
happening?

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"No hay cielo posible sin hundir nuestras raíces
en la profundidad de la tierra" (Malucha Pinto)