Re: Table refer leak in logical replication

On Wed, Apr 21, 2021 at 9:31 AM Michael Paquier <michael@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.

-- 
Amit Langote
EDB: http://www.enterprisedb.com