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

On Thu, Jul 22, 2010 at 06:29:47PM -0400, Robert Haas wrote:
> On Thu, Jul 22, 2010 at 5:01 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Mon, Jul 19, 2010 at 4:35 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >>> 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.
> >> Updated patch attached.
> >
> > Considering that this is a crasher, I think we'll need to back-patch
> > this.  The proposed patch applies only as far back as 8.3, due to the
> > lazy XID assignment changes in that version, but it looks like the bug
> > exists all the way back to 8.0.  It looks like only minor adjustments
> > are required for the older branches, though.  7.4 is not affected, as
> > it does not have subtransactions.
> Can someone provide a reproducible test case for this bug? I wasn't
> easily able to reproduce it.
201007191950(dot)13856(dot)andres(at)anarazel(dot)de contains a test script. You need
to actually do a action causing an xid to get calculated
(heap_(insert|update|delete) basically) after youre deeply stacked.

> Attached please find a cleaned-up version of the patch for CVS HEAD.
> I am having a bit of trouble compiling the 8.2 patch I hacked up, and
> I believe that's because the git respository is borked.
Yes, the "old" git repo is borked. Either use Andrew's from github or
the one from magnus...

Andres