Re: memory leak in logical WAL sender with pgoutput's cachectx - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: memory leak in logical WAL sender with pgoutput's cachectx
Date
Msg-id CAD21AoB1QuYYucbXU+iOtvwEb2Z964h=1HF-UxP+Zs-VT0xLow@mail.gmail.com
Whole thread Raw
In response to memory leak in logical WAL sender with pgoutput's cachectx  ("赵宇鹏(宇彭)" <zhaoyupeng.zyp@alibaba-inc.com>)
List pgsql-hackers
On Wed, Aug 13, 2025 at 11:43 PM 赵宇鹏(宇彭) <zhaoyupeng.zyp@alibaba-inc.com> wrote:
>
> Hi all,
>
> We recently ran into a memory leak in a production logical-replication WAL-sender
> process. A simplified reproduction script is attached.
>
> If you run the script and then call MemoryContextStats(TopMemoryContext). you
> will see something like:
> "logical replication cache context: 562044928 total in 77 blocks;"
> meaning “cachectx” has grown to ~500 MB, and it keeps growing as the number of
> tables increases.
>
> The workload can be summarised as follows:
> 1. CREATE PUBLICATION FOR ALL TABLES
> 2. CREATE SUBSCRIPTION
> 3. Repeatedly CREATE TABLE and DROP TABLE

I'd like to know more about your use cases so that we can better
understand this problem.

In the workload you summarized, many tables are created and dropped.
Do the changes of these tables need to be replicated to the
subscriber? It seems to me that if tables are present in short periods
of time, we can use temp tables instead unless these changes need to
be replicated to the subscribers.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: memory leak in logical WAL sender with pgoutput's cachectx
Next
From: Masahiko Sawada
Date:
Subject: Re: Fix for typo in UUIDv7 timestamp extraction