On Mon, Dec 9, 2024 at 2:06 AM Amit Kapila <amit.kapil...@gmail.com> wrote:
>
> On Thu, Dec 5, 2024 at 2:56 PM Masahiko Sawada <sawada.m...@gmail.com> wrote:
> >
> > >
> > > 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.
> >
>
> It couldn't solve the problem completely even in back-branches. The
> SQL API case I mentioned and tested by Hou-San in the email [1] won't
> be solved.
True. There seems another place where we possibly leak memory on
CacheMemoryContext when using pgoutput via SQL APIs:
/* Map must live as long as the session does. */
oldctx = MemoryContextSwitchTo(CacheMemoryContext);
entry->attrmap = build_attrmap_by_name_if_req(indesc, outdesc, false);
MemoryContextSwitchTo(oldctx);
RelationClose(ancestor);
entry->attrmap is pfree'd only when validating the RelationSyncEntry
so remains even after logical decoding API calls.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
