From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | 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-03 22:41:19 |
Message-ID: | Z0-JD3F-fBx8IwlL@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 03, 2024 at 02:45:22PM +0100, Alvaro Herrera wrote:
> We can put the new member at the end of the struct, it shouldn't damage
> anything even if they're using this struct -- which I find pretty
> unlikely. The only way that could break anything is if somebody is
> allocating/using arrays of it, which sounds even more unlikely.
Yes, that sounds unlikely.
> 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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-12-03 23:02:39 | Re: Proposal for Updating CRC32C with AVX-512 Algorithm. |
Previous Message | Thomas Munro | 2024-12-03 22:36:08 | Re: Windows pg_basebackup unable to create >2GB pg_wal.tar tarballs ("could not close file: Invalid argument" when creating pg_wal.tar of size ~ 2^31 bytes) |