Horton

Re: Table refer leak in logical replication

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>, "tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, "shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>
Date: 2021-04-20T05:09:18Z
Lists: pgsql-hackers 
On Mon, Apr 19, 2021 at 09:44:05PM +0900, Amit Langote wrote:
> Okay, how about the attached then?

create_estate_for_relation() returns an extra resultRelInfo that's
also saved within es_opened_result_relations.  Wouldn't is be simpler
to take the first element from es_opened_result_relations instead?
Okay, that's a nit and you are documenting things in a sufficient way,
but that just seemed duplicated to me.

> I decided to go with just
> finish_estate(), because we no longer have to do anything relation
> specific there.

Fine by me.
--
Michael

Commits

  1. Add more tests with triggers on partitions for logical replication

  2. Fix relation leak for subscribers firing triggers in logical replication

  3. Create ResultRelInfos later in InitPlan, index them by RT index.