Horton

Re: Memory leak in WAL sender with pgoutput (v10~)

Amit Kapila <amit.kapila16@gmail.com>

View thread View on postgr.es
From: Amit Kapila <amit.kapila16@gmail.com>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: Michael Paquier <michael@paquier.xyz>, Euler Taveira <euler@eulerto.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-12-04T05:35:43Z
Lists: pgsql-hackers 
On Wed, Dec 4, 2024 at 7:39 AM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Wednesday, December 4, 2024 8:55 AM Michael Paquier <michael@paquier.xyz> wrote:
> >
>
> > Amit has concerns with other code paths that could be
> > similarly leaking.  I'm not sure if this is worth waiting too long
> > based on how local the fix for the existing leak is with any of these
> > solutions.
>
> It appears there is an additional memory leak caused by allocating publication
> names within the CacheMemoryContext, as noted in [1]. And it can also be fixed by
> creating a separate memctx for publication names under the logical decoding
> context. I think the approach makes sense since the lifespan of publication
> names should ideally align with that of the logical decoding context.
>

Yeah, I don't think we can go with the proposed patch for the local
memory context as it is.

-- 
With Regards,
Amit Kapila.

Commits

  1. Fix memory leak in pgoutput with relation attribute map

  2. Fix memory leak in pgoutput with publication list cache

  3. Allow specifying row filters for logical replication of tables.