Re: nested-xacts cursors (was Re: Performance with new nested-xacts code)

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> Yeah. Another answer would be to reset the executor state if the cursor
> is modified in a subtransaction that aborts:

Reset is no solution --- rewinding the cursor to the beginning still
leaves it in a state that is inconsistent with the restored state of
the bufmgr refcounts, etc. We have to restore the executor tree to the
state it was in when we entered the subtransaction, not any earlier or
later state.

The problem is that that's a *major* bit of work, and probably
impossible to do completely (how are you going to get a user-written SRF
to restore state?). But I think it would be the best solution if we can
think of a reasonable way to do it.

Another idea I've been wondering about involves leaving the cursor's
state alone at subtrans abort, and instead trying to fix up the bufmgr
&etc state to be correct for this situation. This seems not real easy
since I'm not sure how we distinguish state changes associated with
advancing an outer cursor from those associated with
completely-inside-the-subxact operations. But it seems at least
theoretically doable without breaking user SRFs. Also, it's possible
that we could arrange things so that major cost is incurred only when a
subxact actually aborts, rather than in the main-line path of control.
(Expending lots of cycles at every subxact start to save state that
we might never need really sticks in my craw...)

One possible plan of attack for this approach is to abandon the notion
that bufmgr per se is responsible for figuring out what to reset its
state to. Instead we would insist on doing a proper shutdown of
inside-the-transaction portals, and expect that doing so would bring
the refcounts to where they oughta be. I think that this would have
been an unworkably fragile solution back in the day when the present
error recovery approach was designed, because there were too many bugs
and we were often recovering from the effects of those bugs as much as
anything else. But maybe now we could get away with it.

BTW, I've been more or less ignoring the nearby debate about whether
cursors ought to roll back at subxact abort or not, because right now
I don't know how to implement *either* behavior. Unless we have
credible theories about how to implement both, it's a bit useless to
debate which is better.

regards, tom lane