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 по дате отправления: