BUG #17914: walsenders taking up all memory

Поиск
Список
Период
Сортировка
От PG Bug reporting form
Тема BUG #17914: walsenders taking up all memory
Дата
Msg-id 17914-f2ef37f9068914c6@postgresql.org
обсуждение исходный текст
Ответы Re: BUG #17914: walsenders taking up all memory  (Masahiko Sawada <sawada.mshk@gmail.com>)
Re: BUG #17914: walsenders taking up all memory  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-bugs
The following bug has been logged on the website:

Bug reference:      17914
Logged by:          Stan S
Email address:      stashukny@gmail.com
PostgreSQL version: 14.3
Operating system:   AWS RDS - (Red Hat 7.3.1-12), 64-bit
Description:

Seeing the same issue as reported here:
https://www.postgresql.org/message-id/CAMnUB3oYugXCBLSkih%2BqNsWQPciEwos6g_AMbnz_peNoxfHwyw%40mail.gmail.com

In our case, logical_decoding_work_mem is set to 64 MB, yet walsenders can
each take up 30 GB of memory, crashing our database. 

Able to reproduce it locally in docker, using Postgres 14.7 (latest minor
version of 14) following the same instructions as mentioned in
https://www.postgresql.org/message-id/CAMnUB3oYugXCBLSkih%2BqNsWQPciEwos6g_AMbnz_peNoxfHwyw%40mail.gmail.com
which is basically running parallelized update statements on one table on
the publisher, updating it's json column like this:

    UPDATE tab1 SET data = data || '{"test_0": "1", "test_1": "1", "test_2":
"1",
"test_3": "1", "test_4": "1", "test_5": "1", "test_6": "1", "test_7": "1",
"test_8":
"1", "test_9": "1", "test_a": "1", "test_b": "1", "test_c": "1", "test_d":
"1",
"test_e": "1", "test_f": "1"}' #- '{test_0}'

The end result is each walsender's memory usage jumping up many times the
logical_decoding_work_mem limit.


В списке pgsql-bugs по дате отправления:

Предыдущее
От: Alexander Lakhin
Дата:
Сообщение: Re: BUG #17912: Invalid memory access when converting plpython' array containing empty array
Следующее
От: Tobias Bussmann
Дата:
Сообщение: Re: pg_basebackup: errors on macOS on directories with ".DS_Store" files