RE: Table refer leak in logical replication - Mailing list pgsql-hackers

From houzj.fnst@fujitsu.com
Subject RE: Table refer leak in logical replication
Date
Msg-id OS0PR01MB571639608999D27996E038A294489@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Table refer leak in logical replication  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Table refer leak in logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
List 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

pgsql-hackers by date:

Previous
From: ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Date:
Subject: Re: "could not find pathkey item to sort" for TPC-DS queries 94-96
Next
From: Patrik Novotny
Date:
Subject: RFE: Make statistics robust for unplanned events