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

From Michael Paquier
Subject Re: Table refer leak in logical replication
Date
Msg-id YH1ufTvJKsDvAP7y@paquier.xyz
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
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

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Reduce the number of special cases to build contrib modules on windows
Next
From: Justin Pryzby
Date:
Subject: Re: [CLOBBER_CACHE]Server crashed with segfault 11 while executing clusterdb