On Wed, Apr 21, 2021 at 11:13 AM Amit Langote <amitlangot...@gmail.com> wrote: > On Wed, Apr 21, 2021 at 9:31 AM Michael Paquier <mich...@paquier.xyz> wrote: > > 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. > > Agree about adding tests along these lines. Will post in a bit.
Here you go. So I had started last night by adding some tests for this in 003_constraints.pl because there are already some replica BR trigger tests there. I like your suggestion to have some tests around partitions, so added some in 013_partition.pl too. Let me know what you think. -- Amit Langote EDB: http://www.enterprisedb.com
fix_relcache_leak_in_lrworker_v7.patch
Description: Binary data
