On Tue, Dec 10, 2024 at 2:17 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > 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. >
We have also noticed this but it needs more analysis on the fix which one of my colleagues is doing. I think we can fix this as a separate issue unless you think otherwise. -- With Regards, Amit Kapila.
