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

From Alvaro Herrera
Subject Re: Memory leak in WAL sender with pgoutput (v10~)
Date
Msg-id 202412031033.unnvfx7r2z7p@alvherre.pgsql
Whole thread Raw
Responses Re: Memory leak in WAL sender with pgoutput (v10~)
List pgsql-hackers
On 2024-Dec-03, Michael Paquier wrote:

> So how about the attached that introduces a FreePublication() matching
> with GetPublication(), used to do the cleanup?  Feel free to comment.

I think this doubles down on bad design in the logical replication code,
or at least it goes against what we do almost everywhere else in backend
code.  We should do less freeing, more context deleting/resetting.
(Storing stuff in CacheMemoryContext was surely a mistake.)

If you don't like the idea of a static memcxt in the one block where
it's needed, I propose to store a new memcxt in PGOutputData, to be used
exclusively for publications, with a well defined lifetime.  I'm against
reusing data->cachecxt, because the lifetime of that is 100% unclear.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/



pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: relfilenode statistics
Next
From: "Anton A. Melnikov"
Date:
Subject: Re: shared-memory based stats collector - v70