Horton

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

Masahiko Sawada <sawada.mshk@gmail.com>

View thread View on postgr.es
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: Michael Paquier <michael@paquier.xyz>, Amit Kapila <amit.kapila16@gmail.com>, Euler Taveira <euler@eulerto.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-12-05T09:25:51Z
Lists: pgsql-hackers 
On Thu, Dec 5, 2024 at 1:32 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Wednesday, December 4, 2024 7:39 PM Michael Paquier <michael@paquier.xyz> wrote:
> >
> > On Wed, Dec 04, 2024 at 06:42:55AM +0000, Zhijie Hou (Fujitsu) wrote:
> > > I can try to write a patch if no one else is working on this.
> >
> > If you have some room to write a patch, that would be really nice.
> > Thanks.
>
> No problem. Here is the patch for the HEAD. This patch introduces a new memory
> context within PGOutputData, specifically for allocating memory for
> publication_names. The new memory context is nested under the logical decoding
> context, ensuring it is freed at the end of decoding through
> FreeDecodingContext.

+1 for using new memory context to fix the issue for HEAD.

>
> 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. I think we can live with such (a bit of) ugliness on back
branches.

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.