Re: Table refer leak in logical replication
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>
Cc: Amit Langote <amitlangote09@gmail.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, "shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>,
"tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>, Masahiko Sawada <sawada.mshk@gmail.com>,
Michael Paquier <michael@paquier.xyz>
Date: 2021-04-20T12:50:03Z
Lists: pgsql-hackers
On Tue, Apr 20, 2021 at 4:59 PM houzj.fnst@fujitsu.com <houzj.fnst@fujitsu.com> wrote: > > > > ... FWIW, I'd rather > > > agree to use what has been proposed with es_opened_result_relations > > > like TRUNCATE does rather than attempt to use ExecInitResultRelation() > > > combined with potentially asymmetric calls to > > > ExecCloseResultRelations(). > > > > Okay, how about the attached then? I decided to go with just finish_estate(), > > because we no longer have to do anything relation specific there. > > > > I think the patch looks good. > But I noticed that there seems no testcase to test the [aftertrigger in subscriber] when using logical replication. > As we seems planned to do some further refactor in the future, Is it better to add one testcase to cover this code ? > +1. I think it makes sense to add a test case especially because we don't have any existing test in this area. -- With Regards, Amit Kapila.
Commits
-
Add more tests with triggers on partitions for logical replication
- 2ecfeda3e916 14.0 landed
-
Fix relation leak for subscribers firing triggers in logical replication
- f3b141c48255 14.0 landed
-
Create ResultRelInfos later in InitPlan, index them by RT index.
- 1375422c7826 14.0 cited