Re: BUG #5566: High levels of savepoint nesting trigger stack overflow in AssignTransactionId

On Monday 19 July 2010 20:19:35 Heikki Linnakangas wrote:
> On 19/07/10 20:58, Andres Freund wrote:
> > On Monday 19 July 2010 19:57:13 Alvaro Herrera wrote:
> >> Excerpts from Andres Freund's message of lun jul 19 11:58:06 -0400 2010:
> >>> On Monday 19 July 2010 17:26:25 Hans van Kranenburg wrote:
> >>>> When issuing an update statement in a transaction with ~30800 levels
> >>>> of savepoint nesting, (which is insane, but possible), postgresql
> >>>> segfaults due to a stack overflow in the AssignTransactionId
> >>>> function, which recursively assign transaction ids to parent
> >>>> transactions.
> >>>
> >>> It seems easy enough to throw a check_stack_depth() in there - survives
> >>> make check here.
> >>
> >> I wonder if it would work to deal with the problem non-recursively
> >> instead. We don't impose subxact depth restrictions elsewhere, why
> >> start now?
> >
> > It looks trivial enough, but whats the point?
>
> To support more than <insert abitrary limit here> subtransactions,
> obviously.
Well. I got that far. But why is that something worthy of support?
For one I have a hard time imaging a sensible use case, for another doing
anything in that deeply nested transactions seems to gets really slow (the
chain of transactions gets walked at some places for one thing, there seem to
be others).

If want I can write a patch for that as well, seems to be trivial enough.

Andres