Re: BUG #14231: logical replication wal sender process spins when using error traps in function
От | Andrew Gierth |
---|---|
Тема | Re: BUG #14231: logical replication wal sender process spins when using error traps in function |
Дата | |
Msg-id | 878txea5b4.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | BUG #14231: logical replication wal sender process spins when using error traps in function (blake@rcmail.com) |
Ответы |
Re: BUG #14231: logical replication wal sender process spins
when using error traps in function
Re: BUG #14231: logical replication wal sender process spins when using error traps in function |
Список | pgsql-bugs |
>>>>> "blake" == blake <blake@rcmail.com> writes: blake> Connect a logical client with test_decoding plugin and run the blake> code below. It will cause the replication process to spin, blake> using 100% CPU for some long period of time. So what I've found in my analysis so far since you mentioned this on IRC is: 1. The time is being spent in ReorderBufferCleanupTXN and the functions it calls. This is called once for the transaction and (recursively) once per subtransaction. 2. Within each of those calls, the main culprit seems to be pathological behavior of the retail pfree() calls of allocated memory. The loop in AllocSetFree which chases down the allocated block list (for chunks over the chunk limit) is being executed nearly 900 million times for what seems to be about 42 thousand calls. A quick scan of the code suggests that the worst case is when blocks are being freed in FIFO order, which seems quite plausible in this case, and the performance is potentially O(N^2). So I think this is primarily an artifact of doing so much retail palloc/pfree in a single memory context. -- Andrew (irc:RhodiumToad)
В списке pgsql-bugs по дате отправления: