Re: memory leak in logical WAL sender with pgoutput's cachectx

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: 赵宇鹏(宇彭) <zhaoyupeng(dot)zyp(at)alibaba-inc(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: memory leak in logical WAL sender with pgoutput's cachectx
Date: 2025-08-15 18:29:24
Message-ID: CAD21AoB1QuYYucbXU+iOtvwEb2Z964h=1HF-UxP+Zs-VT0xLow@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 13, 2025 at 11:43 PM 赵宇鹏(宇彭) <zhaoyupeng(dot)zyp(at)alibaba-inc(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-08-15 18:44:53 Re: Fix for typo in UUIDv7 timestamp extraction
Previous Message Masahiko Sawada 2025-08-15 18:22:06 Re: memory leak in logical WAL sender with pgoutput's cachectx