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

From Zhijie Hou (Fujitsu)
Subject RE: Memory leak in WAL sender with pgoutput (v10~)
Date
Msg-id OS0PR01MB571696F0DCA5D253B6C2E6AC94362@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Memory leak in WAL sender with pgoutput (v10~)  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Tuesday, December 3, 2024 4:43 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> 
> On 2024-Dec-02, Amit Kapila wrote:
> > > 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.
> >
> > BTW, the subscription structure also used the name in a similar way.
> > This will make the publication/subscription names handled differently.
> 
> True (with conninfo, slotname, synccommit, and origin).
...
>
> (Why are we storing a string in Subscription->synccommit?)

I think it's because the primary purpose of sub->synccommit is to serve as a
parameter for SetConfigOption() in the apply worker, which requires a string
value. Additionally, the existing function set_config_option() that validates
this option only accepts a string input. Although we could convert
sub->synccommit to an integer, this would necessitate additional conversion
code before passing it to these functions.

Best Regards,
Hou zj

pgsql-hackers by date:

Previous
From: Nazir Bilal Yavuz
Date:
Subject: Re: meson missing test dependencies
Next
From: Kirill Reshke
Date:
Subject: Re: Sequence Access Methods, round two