Re: Memory leak in WAL sender with pgoutput (v10~)
От | Masahiko Sawada |
---|---|
Тема | Re: Memory leak in WAL sender with pgoutput (v10~) |
Дата | |
Msg-id | CAD21AoCz2DERxE8sY4LYPP2WhcUCMX5vWHWid8XQ8KzxpEDjqg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Memory leak in WAL sender with pgoutput (v10~) (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Memory leak in WAL sender with pgoutput (v10~)
|
Список | pgsql-hackers |
On Thu, Dec 5, 2024 at 1:32 PM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote: > > On Wednesday, December 4, 2024 7:39 PM Michael Paquier <michael@paquier.xyz> wrote: > > > > On Wed, Dec 04, 2024 at 06:42:55AM +0000, Zhijie Hou (Fujitsu) wrote: > > > I can try to write a patch if no one else is working on this. > > > > If you have some room to write a patch, that would be really nice. > > Thanks. > > No problem. Here is the patch for the HEAD. This patch introduces a new memory > context within PGOutputData, specifically for allocating memory for > publication_names. The new memory context is nested under the logical decoding > context, ensuring it is freed at the end of decoding through > FreeDecodingContext. +1 for using new memory context to fix the issue for HEAD. > > I realized that this patch cannot be backpatched because it introduces a new > field into the public PGOutputData structure. Therefore, I think we may need to > use Alvaro's version [1] for the back branches. FWIW for back branches, I prefer using the foreach-pfree pattern Michael first proposed, just in case. It's not elegant but it can solve the problem while there is no risk of breaking non-core extensions. I think we can live with such (a bit of) ugliness on back branches. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: