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

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: memory leak in logical WAL sender with pgoutput's cachectx
Дата
Msg-id CAD21AoB1QuYYucbXU+iOtvwEb2Z964h=1HF-UxP+Zs-VT0xLow@mail.gmail.com
обсуждение исходный текст
Ответ на memory leak in logical WAL sender with pgoutput's cachectx  ("赵宇鹏(宇彭)" <zhaoyupeng.zyp@alibaba-inc.com>)
Ответы Re: memory leak in logical WAL sender with pgoutput's cachectx
Список 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 по дате отправления: