Re: Forget close an open relation in ReorderBufferProcessTXN()

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Japin Li <japinli(at)hotmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Forget close an open relation in ReorderBufferProcessTXN()
Date: 2021-04-20 03:06:44
Message-ID: CA+HiwqFCvEK7aefcWGjX=DEnQeOP0OZwwxR2eT6OX7cAVQj-HA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 17, 2021 at 1:30 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Fri, Apr 16, 2021 at 11:24 PM Andres Freund <andres(at)anarazel(dot)de> wrote:> > This made me take a brief look at pgoutput.c - maybe I am missing
> > something, but how is the following not a memory leak?
> >
> > static void
> > maybe_send_schema(LogicalDecodingContext *ctx,
> > ReorderBufferTXN *txn, ReorderBufferChange *change,
> > Relation relation, RelationSyncEntry *relentry)
> > {
> > ...
> > /* Map must live as long as the session does. */
> > oldctx = MemoryContextSwitchTo(CacheMemoryContext);
> > relentry->map = convert_tuples_by_name(CreateTupleDescCopy(indesc),
> > CreateTupleDescCopy(outdesc));
> > MemoryContextSwitchTo(oldctx);
> > send_relation_and_attrs(ancestor, xid, ctx);
> > RelationClose(ancestor);
> >
> > If - and that's common - convert_tuples_by_name() won't have to do
> > anything, the copied tuple descs will be permanently leaked.
> >
>
> I also think this is a permanent leak. I think we need to free all the
> memory associated with this map on the invalidation of this particular
> relsync entry (basically in rel_sync_cache_relation_cb).

I agree there's a problem here.

Back in:

https://www.postgresql.org/message-id/CA%2BHiwqEeU19iQgjN6HF1HTPU0L5%2BJxyS5CmxaOVGNXBAfUY06Q%40mail.gmail.com

I had proposed to move the map creation from maybe_send_schema() to
get_rel_sync_entry(), mainly because the latter is where I realized it
belongs, though a bit too late. Attached is the part of the patch
for this particular issue. It also takes care to release the copied
TupleDescs if the map is found to be unnecessary, thus preventing
leaking into CacheMemoryContext.

--
Amit Langote
EDB: http://www.enterprisedb.com

Attachment Content-Type Size
pgoutput-map-tupdesc-leak.patch application/octet-stream 2.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-04-20 03:06:55 Re: pg_amcheck option to install extension
Previous Message Julien Rouhaud 2021-04-20 03:02:31 Re: Bogus collation version recording in recordMultipleDependencies