Re: Memory leak in WAL sender with pgoutput (v10~)

On Mon, Dec 09, 2024 at 12:46:35PM -0800, Masahiko Sawada wrote:
> 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.

Right. I'm also slightly worried about how we handle streamed_txns in
set_schema_sent_in_streamed_txn() through CacheMemoryContext. It
feels like this could be made more robust without relying on an
explicit list_free() in get_rel_sync_entry(), including the fact that
some cleanup also relies on pgoutput_stream_abort() being taken.

As a whole, thinking long-term, it seems to me that we'd live better
if we remove all direct dependencies to CacheMemoryContext in this
code.
--
Michael