From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Subject: | Re: Memory leak in WAL sender with pgoutput (v10~) |
Date: | 2024-12-02 20:29:41 |
Message-ID: | 202412022029.i5ve5njg3ask@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2024-Dec-02, Michael Paquier wrote:
> I am slightly concerned about the current design of GetPublication()
> in the long-term, TBH. LoadPublications() has hidden the leak behind
> two layers of routines in the WAL sender, and that's easy to miss once
> you call anything that loads a Publication depending on how the caller
> caches its data. So I would still choose for modifying the structure
> on HEAD removing the pstrdup() for the publication name. Anyway, your
> suggestion is also OK by me on top of that, that's less conflicts in
> all the branches.
TBH I'm not sure that wastefully allocating NAMEDATALEN for each
relation is so great. Our strategy for easing memory management is to
use appropriately timed contexts.
I guess if you wanted to make a publication a single palloc block (so
that it's easy to free) and not waste so much memory, you could stash
the name string at the end of the struct. I think that'd be a change
wholly contained in GetPublication.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
Are you not unsure you want to delete Firefox?
[Not unsure] [Not not unsure] [Cancel]
http://smylers.hates-software.com/2008/01/03/566e45b2.html
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2024-12-02 20:42:52 | Re: Memory leak in WAL sender with pgoutput (v10~) |
Previous Message | Alena Rybakina | 2024-12-02 20:12:05 | Re: Vacuum statistics |