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:
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 |
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 |