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 Kapila <amit.kapila16@gmail.com>
Cc: Amit Langote <amitlangote09@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-19T06:12:36Z
Lists: pgsql-hackers 
On Mon, Apr 19, 2021 at 03:08:41PM +0900, Michael Paquier wrote:
> FWIW, I
> would be tempted to send back f1ac27b to the blackboard, then refactor
> the code of the apply worker to use ExecInitResultRelation() so as we
> get more consistency with resource releases, simplifying the business
> with indexes.  Once the code is in a cleaner state, we could come back
> into making an integration with partitioned tables into this code.

But you cannot do that either as f1ac27bf got into 13..
--
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.