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

Masahiko Sawada <sawada.mshk@gmail.com>

From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, 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-09T20:46:35Z
Lists: pgsql-hackers
On Mon, Dec 9, 2024 at 2:06 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Dec 5, 2024 at 2:56 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > >
> > > I realized that this patch cannot be backpatched because it introduces a new
> > > field into the public PGOutputData structure. Therefore, I think we may need to
> > > use Alvaro's version [1] for the back branches.
> >
> > FWIW for back branches, I prefer using the foreach-pfree pattern
> > Michael first proposed, just in case. It's not elegant but it can
> > solve the problem while there is no risk of breaking non-core
> > extensions.
> >
>
> 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.

True. There seems another place where we possibly leak memory on
CacheMemoryContext when using pgoutput via SQL APIs:

        /* Map must live as long as the session does. */
        oldctx = MemoryContextSwitchTo(CacheMemoryContext);

        entry->attrmap = build_attrmap_by_name_if_req(indesc, outdesc, false);

        MemoryContextSwitchTo(oldctx);
        RelationClose(ancestor);

entry->attrmap is pfree'd only when validating the RelationSyncEntry
so remains even after logical decoding API calls.


Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



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.