Andres Freund <andres@anarazel.de> writes:
> On 2017-10-05 17:43:39 -0400, Tom Lane wrote:
>> Nah, I take that back. The AbortCurrentTransaction call looks funny
>> (and is sadly underdocumented) but it's not invalid to call it and
>> then call RollbackAndReleaseCurrentSubTransaction.
> It's not perfectly documented, but there's some:
What I'm on about is that I think the AbortCurrentTransaction call needs a
comment along the lines of
* Roll back the current (sub)transaction. In the using_subtxn * case, we could leave it to
RollbackAndReleaseCurrentSubTransaction* to do this, but we do it separately anyway because XYZ.
It's the fact that XYZ isn't very obvious that makes this comment
necessary. I'm guessing it's because ReorderBufferExecuteInvalidations
either doesn't work or is less efficient if inside a still-valid
transaction, but the fact that I need to guess is the problem.
>> I'm not sure about a good way to fix #2 without re-introducing the memory
>> leaks that call was added to fix (cf 7ec1c5a86).
> I think I don't fully understand what 7ec1c5a86 is trying to
> achieve.
I dug around in the archives and found
https://www.postgresql.org/message-id/26365.1162532453%40sss.pgh.pa.us
The function shown there doesn't appear to leak any memory at all in HEAD,
but if you dike out the memory context reset in question, it leaks like
crazy. I didn't try to reconfirm my old estimate of 16KB per iteration,
but it seemed to be in that ballpark still.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs