Re: relcache refcount

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.

> Incidentally, I assume that LWLocks are not going to be needed across
> subtransaction boundaries -- I release them all on abort, just as it's
> done on main transaction abort. Same for catcache entries. Does anyone
> think this is incorrect?

Sounds like a very unsafe assumption to me. The reason we can get away
with force-to-zero logic for these things now is that we know we are
reverting to an idle condition. The general solution would require
reverting to the state prevailing at subtrans entry. If you want to
avoid implementing the general solution for any particular backend
module, you'd better be able to prove that it will be in an idle state
at every subtrans entry. It's barely possible that that's true for
LWLocks but I've got real serious doubts about catcache. As an example:
mightn't the call handler for a procedural language hold onto a
reference to the proc's pg_proc row throughout execution? Even if it
chances not to do that today, somebody could easily want to do it
tomorrow, so I think an assumption that it's not needed would be too
fragile.

BTW, what are your plans for state saving/reversion for the lock manager
and buffer manager? The lock state, in particular, makes these other
problems look trivial by comparison.

Glad to see you are starting to realize why nested transactions haven't
been done already ;-)

regards, tom lane