Re: Table refer leak in logical replication - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Table refer leak in logical replication
Date
Msg-id CA+HiwqHHFEzLxBQ+jgXo3wOK15ZK-7a8tDPJ57Sp9WbMCRGUCA@mail.gmail.com
Whole thread Raw
In response to Re: Table refer leak in logical replication  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Table refer leak in logical replication
Re: Table refer leak in logical replication
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: terminate called after throwing an instance of 'std::bad_alloc'
Next
From: Tom Lane
Date:
Subject: Re: [bug?] Missed parallel safety checks, and wrong parallel safety