Horton

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

Euler Taveira <euler@eulerto.com>

View thread View on postgr.es
From: "Euler Taveira" <euler@eulerto.com>
To: "Michael Paquier" <michael@paquier.xyz>, "Alvaro Herrera" <alvherre@alvh.no-ip.org>
Cc: "Amit Kapila" <amit.kapila16@gmail.com>, "Postgres hackers" <pgsql-hackers@lists.postgresql.org>
Date: 2024-12-04T00:46:06Z
Lists: pgsql-hackers 
On Tue, Dec 3, 2024, at 7:41 PM, Michael Paquier wrote:
> On Tue, Dec 03, 2024 at 02:45:22PM +0100, Alvaro Herrera wrote:
> > If we don't want to accept that risk (for which I see no argument, but
> > happy to be proven wrong), I would suggest to use the foreach-pfree
> > pattern Michael first proposed for the backbranches, and the new memory
> > context in master.  I think this is conducive to better coding overall
> > as we clean things up in this area.
> 
> Is it really worth betting on nobody doing something that does a
> sizeof(PGOutputData) for the stable branches?  People like doing fancy
> things, and we would not hear about such problems except if we push
> the button making it a possibility because compiled code suddenly
> breaks after a minor release update of the core engine.

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.

[1] https://codesearch.debian.net/search?q=PGOutputData&literal=0

--
Euler Taveira
EDB   https://www.enterprisedb.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.