RE: Table refer leak in logical replication
Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
From: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: "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>, Amit Kapila <amit.kapila16@gmail.com>
Date: 2021-04-20T11:29:43Z
Lists: pgsql-hackers
> > ... 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 ? Best regards, houzj
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