Re: Memory leak in WAL sender with pgoutput (v10~) - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Memory leak in WAL sender with pgoutput (v10~)
Date
Msg-id CAA4eK1J82KuGhwwR-wJ6Mo_ExojUTgQwY4cK7OBtzdVgoxtjCg@mail.gmail.com
Whole thread Raw
In response to Re: Memory leak in WAL sender with pgoutput (v10~)  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Wed, Dec 18, 2024 at 12:32 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Tue, Dec 17, 2024 at 2:48 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> >
> > Will fix_memory_leak_v3.patch avoid the leak in case of an ERROR in
> > SQL API? If so, how?
>
> The pubctx is created as a child of LogicalDecodingContext->context.
> On an error, the pubctx is cleaned up altogether when cleaning up
> LogicalDecodingContext->context.
>

The difference between fix_memory_leak_v2 and fix_memory_leak_v3 is
that the earlier one resets the pubctx to NULL along with freeing the
context memory. Resetting a file-level global variable is a good idea,
similar to what we do for RelationSyncCache, so I prefer v2 over v3,
but I am fine if you would like to proceed with v3.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Back-patch of: avoid multiple hard links to same WAL file after a crash
Next
From: Tom Lane
Date:
Subject: Re: Converting SetOp to read its two inputs separately