On 2017-10-05 19:42:30 -0400, Tom Lane wrote:
> >> 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.
I knew that I disliked SPI, but I forgot how much I disliked it :(. I
think one of these years we should really replace it - it quite
frequently comes up as problematic.
I was wondering if the appropriate fix here wouldn't be to just always
do an SPI_connect()/finish() inside such subtransactions - that feels
more correct. But it's not easy due to the way memory management's done
in plpgsql (and presumably elsewhere) :(.
So far your option of allowing to opt in into additional cleanup in the
CATCH seems the least ugly
I'm kinda surprised that this only causes problems with logical decoding
and not elsewhere, this isn't a new issue.
Greetings,
Andres Freund
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
