Re: Table refer leak in logical replication
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>, 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>
Date: 2021-04-21T00:31:34Z
Lists: pgsql-hackers
On Tue, Apr 20, 2021 at 06:20:03PM +0530, Amit Kapila wrote: > +1. I think it makes sense to add a test case especially because we > don't have any existing test in this area. Yes, let's add add something into 013_partition.pl within both subscriber1 and subscriber2. This will not catch up the relation leak, but it is better to make sure that the trigger is fired as we'd like to expect. This will become helpful if this code gets refactored or changed in the future. What about adding an extra table inserted into by the trigger itself? If I were to design that, I would insert the following information that gets checked by a simple psql call once the changes are applied in the subscriber: relation name, TG_WHEN, TG_OP and TG_LEVEL. So such a table would need at least 4 columns. -- Michael
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