Re: Table refer leak in logical replication

On Wed, Apr 21, 2021 at 11:13 AM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Wed, Apr 21, 2021 at 9:31 AM Michael Paquier <michael(at)paquier(dot)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