RE: Table refer leak in logical replication

From: "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "shiy(dot)fnst(at)fujitsu(dot)com" <shiy(dot)fnst(at)fujitsu(dot)com>
Subject: RE: Table refer leak in logical replication
Date: 2021-04-06 06:03:42
Message-ID: OS0PR01MB6113BA0A760C9964A4A0C5C2FB769@OS0PR01MB6113.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tuesday, April 6, 2021 2:25 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
>While updating the patch to do so, it occurred to me that maybe we
>could move the ExecInitResultRelation() call into
>create_estate_for_relation() too, in the spirit of removing
>duplicative code. See attached updated patch.

Thanks for your fixing. The code LGTM.
Made a confirmation right now, the problem has been solved after applying your patch.

Regards,
Tang

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2021-04-06 06:20:56 Re: policies with security definer option for allowing inline optimization
Previous Message Andres Freund 2021-04-06 05:59:12 Re: subtransaction performance regression [kind of] due to snapshot caching