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 CAA4eK1+1p4MsJZcP75amWwUpSnHMWUcVBRERHgFwbr6hj2dA3A@mail.gmail.com
Whole thread Raw
In response to Re: Memory leak in WAL sender with pgoutput (v10~)  ("Euler Taveira" <euler@eulerto.com>)
Responses Re: Memory leak in WAL sender with pgoutput (v10~)
List pgsql-hackers
On Tue, Dec 10, 2024 at 8:54 AM vignesh C <vignesh21@gmail.com> wrote:
>
> On Tue, 10 Dec 2024 at 04:56, Michael Paquier <michael@paquier.xyz> wrote:
> >
> > On Mon, Dec 09, 2024 at 03:36:15PM +0530, Amit Kapila wrote:
> > > It couldn't solve the problem completely even in back-branches. The
> > > SQL API case I mentioned and tested by Hou-San in the email [1] won't
> > > be solved.
> > >
> > > [1] -
https://www.postgresql.org/message-id/OS0PR01MB57166A4DA0ABBB94F2FBB28694362%40OS0PR01MB5716.jpnprd01.prod.outlook.com
> >
> > Yeah, exactly (wanted to reply exactly that yesterday but lacked time,
> > thanks!).
>
> Yes, that makes sense. How about something like the attached patch.
>

- oldctx = MemoryContextSwitchTo(CacheMemoryContext);
- if (data->publications)
- {
- list_free_deep(data->publications);
- data->publications = NIL;
- }
+ static MemoryContext pubctx = NULL;
+
+ if (pubctx == NULL)
+ pubctx = AllocSetContextCreate(CacheMemoryContext,
+    "logical replication publication list context",
+    ALLOCSET_SMALL_SIZES);
+ else
+ MemoryContextReset(pubctx);
+
+ oldctx = MemoryContextSwitchTo(pubctx);

Considering the SQL API case, why is it okay to allocate this context
under CacheMemoryContext?

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Skip collecting decoded changes of already-aborted transactions
Next
From: Dilip Kumar
Date:
Subject: Re: Skip collecting decoded changes of already-aborted transactions