| From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "shiy(dot)fnst(at)fujitsu(dot)com" <shiy(dot)fnst(at)fujitsu(dot)com>, "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Subject: | Re: Table refer leak in logical replication |
| Date: | 2021-04-21 02:13:06 |
| Message-ID: | CA+HiwqHHFEzLxBQ+jgXo3wOK15ZK-7a8tDPJ57Sp9WbMCRGUCA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Amit Langote
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-04-21 02:22:40 | Re: [bug?] Missed parallel safety checks, and wrong parallel safety |
| Previous Message | Justin Pryzby | 2021-04-21 02:12:50 | Re: terminate called after throwing an instance of 'std::bad_alloc' |