Re: Table refer leak in logical replication

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: Table refer leak in logical replication
Дата
Msg-id CA+HiwqHHFEzLxBQ+jgXo3wOK15ZK-7a8tDPJ57Sp9WbMCRGUCA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Table refer leak in logical replication  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Table refer leak in logical replication
Re: Table refer leak in logical replication
Список 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 по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: terminate called after throwing an instance of 'std::bad_alloc'
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [bug?] Missed parallel safety checks, and wrong parallel safety