Re: Memory leak in WAL sender with pgoutput (v10~) - Mailing list pgsql-hackers

From Euler Taveira
Subject Re: Memory leak in WAL sender with pgoutput (v10~)
Date
Msg-id 1baea8f8-6c13-42a5-abee-934d452707ef@app.fastmail.com
Whole thread Raw
In response to Re: Memory leak in WAL sender with pgoutput (v10~)  (Amit Kapila <amit.kapila16@gmail.com>)
List 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.


--
Euler Taveira

pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: Serverside SNI support in libpq
Next
From: "Anton A. Melnikov"
Date:
Subject: Re: shared-memory based stats collector - v70