Jeff Davis <pgsql@j-davis.com> writes:
> 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.
Yeah. The problem I saw with it is that it's only "bulletproof" to the
extent that we get that accounting exactly right, and keep it so over
time. I think that assumption is sufficiently fragile that the extra
safety would be illusory. There's a lot of stuff that happens during
AbortTransaction :-(
>> 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?
Well, it'd be an extra however-many-KB of memory for each backend that
would mostly go unused. The rest of a backend's working memory pretty
much pulls its weight, but a TransactionAbortContext wouldn't. OTOH,
maybe these days a few dozen KB isn't worth worrying about.
regards, tom lane