Horton

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

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Euler Taveira <euler@eulerto.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Amit Kapila <amit.kapila16@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-12-04T00:55:16Z
Lists: pgsql-hackers 
On Tue, Dec 03, 2024 at 09:46:06PM -0300, Euler Taveira wrote:
> Although, Debian code search [1] says this data structure is not used outside
> PostgreSQL, I wouldn't risk breaking third-party extensions during a minor
> upgrade (even if it is known that such data structure is from that particular
> output plugin -- pgoutput -- and other output plugins generally have its own
> data structure). +1 from Alvaro's proposal.

A lookup of the public repos of github did not show fancy with the
manipulation of the structure for peoject related to Postgres, either.

FWIW, I'm OK with the memory context reset solution as much as the
direct free calls as we are sure that they will be safe.  And at the
end of the day, the problem would be solved with any of these
solutions.  My votes would be +0.6 for the free and +0.5 for the mcxt
manipulation, so let's say that they are tied.

As Alvaro and yourself are in favor of the mcxt approach, then let's
go for it.  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.
--
Michael

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.