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-19T11:50:21Z
Lists: pgsql-hackers 
On Mon, Apr 19, 2021 at 08:09:05PM +0900, Amit Langote wrote:
> On Mon, Apr 19, 2021 at 7:00 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>> It seems like the memory will be freed after we apply the truncate
>> because we reset the ApplyMessageContext after applying each message,
>> so maybe we don't need to bother about it.
> 
> Yes, ApplyMessageContext seems short-lived enough for this not to
> matter.  In the case of ExecuteTruncateGuts(), it's PortalContext, but
> we don't seem to bother about leaking into that one too.

Sorry for the dump question because I have not studied this part of
the code in any extensive way, but how many changes at maximum can be
applied within a single ApplyMessageContext?  I am wondering if we
could run into problems depending on the number of relations touched
within a single message, or if there are any patches that could run
into problems because of this limitation, meaning that we may want to
add a proper set of comments within this area to document the
limitations attached to a DML operation applied.
--
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.