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: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-12-03T22:41:19Z
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

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.