RE: Table refer leak in logical replication

From: "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: "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>, Michael Paquier <michael(at)paquier(dot)xyz>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: RE: Table refer leak in logical replication
Date: 2021-04-20 11:29:43
Message-ID: OS0PR01MB571639608999D27996E038A294489@OS0PR01MB5716.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > ... 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 ?

Best regards,
houzj

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Patrik Novotny 2021-04-20 11:59:44 RFE: Make statistics robust for unplanned events
Previous Message Dagfinn Ilmari Mannsåker 2021-04-20 11:11:31 Re: "could not find pathkey item to sort" for TPC-DS queries 94-96