From: | "Euler Taveira" <euler(at)eulerto(dot)com> |
---|---|
To: | "Michael Paquier" <michael(at)paquier(dot)xyz>, "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | "Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com>, "Postgres hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Memory leak in WAL sender with pgoutput (v10~) |
Date: | 2024-12-04 00:46:06 |
Message-ID: | 1baea8f8-6c13-42a5-abee-934d452707ef@app.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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/
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-12-04 00:55:16 | Re: Memory leak in WAL sender with pgoutput (v10~) |
Previous Message | Anton A. Melnikov | 2024-12-04 00:45:13 | Re: Missing LWLock protection in pgstat_reset_replslot() |