Re: Table refer leak in logical replication

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Table refer leak in logical replication
Дата
Msg-id CAA4eK1J0F4-PAh3rgUoPMM0o4=9ZsS5D-1oVBaDC8W=zv-UdoQ@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Table refer leak in logical replication  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Ответы Re: Table refer leak in logical replication
Список pgsql-hackers
On Tue, Apr 20, 2021 at 4:59 PM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:
>
> > > ... FWIW, I'd rather
> > > agree to use what has been proposed with es_opened_result_relations
> > > like TRUNCATE does rather than attempt to use ExecInitResultRelation()
> > > combined with potentially asymmetric calls to
> > > ExecCloseResultRelations().
> >
> > Okay, how about the attached then?  I decided to go with just finish_estate(),
> > because we no longer have to do anything relation specific there.
> >
>
> I think the patch looks good.
> But I noticed that there seems no testcase to test the [aftertrigger in subscriber] when using logical replication.
> As we seems planned to do some further refactor in the future, Is it better to add one testcase to cover this code ?
>

+1. I think it makes sense to add a test case especially because we
don't have any existing test in this area.


-- 
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg_amcheck option to install extension
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: pg_amcheck option to install extension