Re: [BUGS] Out of memory error causes Abort, Abort tries

On Wed, 2006-11-22 at 13:06 -0500, Tom Lane wrote:
> > Seems like it'd be smarter to try to free some memory before we push
> > forward with transaction abort. ErrorContext has only a limited amount
> > of space ...
>
> I've been thinking more about this problem. There are two basic
> strategies we could follow to ensure that AbortTransaction has some
> room to work in:
> A: Try to free space before we start the actual abort.
> B: Keep some reserved space for AbortTransaction to use.
> (It seems untenable to try not to ever alloc any memory at all during
> AbortTransaction.) I'm not sure that either of these can be a 100%
> bulletproof solution. As long as there is state data we daren't throw

When I was trying to devise a "bulletproof" solution, it seemed the only
way would be to reserve space, but to increase the reserved space
whenever the state changed such that an AbortTransaction would need
extra memory. This didn't seem worth the accounting effort. I made an
attempt, but gave up (I spent all my time in gdb keeping track of which
memory context I was in). If there are a limited number of areas that
increase potential AbortTransaction memory usage, it's a possibility I
suppose. Otherwise, I don't know how we'd expect code authors to know
whether their code increases memory requirements for AbortTransaction.

> away until after AbortTransaction, plan A doesn't help if we've filled
> memory with that type of data. And plan B doesn't help if
> AbortTransaction needs more memory than we reserved; which seems
> possible for any acceptable level of reserved space (eg consider cases
> with many thousands of subtransactions or deleted files ... we have to
> build a very large XLOG Abort record then).
>
> I think our best answer is probably to do some of each. For (A) it
> seems that we should try to flush the pending-trigger-event list and
> any executor state data that may be hanging around; those are the things

That seems like a relatively easy way to eliminate most of the problem.
It might not be 100% bulletproof, but it will drastically reduce the
chances of causing problems in "normal" situations. I'd certainly be
happy with this fix.

> that seem both easy to delete and likely to be pretty large. For (B)
> there's basically a choice of whether to try to re-use ErrorContext,
> or create a separate context used only for the purposes of running
> AbortTransaction. The separate context would avoid any possibility of
> entanglement between what are really different subsystems, but OTOH it
> seems a bit wasteful.
>

Wasteful how? Do you mean that it would clutter the code, or that it
would cause unnecessary overhead?

Regards,
Jeff Davis