Proposal: Limitations of palloc inside checkpointer
Ekaterina Sokolova <e.sokolova@postgrespro.ru>
From: Ekaterina Sokolova <e.sokolova@postgrespro.ru>
To: pgsql-hackers@lists.postgresql.org
Date: 2025-02-25T19:44:33Z
Lists: pgsql-hackers
Hi, hackers! Historically, the checkpointer process use palloc() into AbsorbSyncRequests() function. Therefore, the checkpointer does not expect to receive a request larger than 1 GB. We encountered a case where the database went into recovery state, after applying all wal, the checkpointer process generated an "invalid memory alloc request size" error and entered a loop. But it is quite acceptable for the recovery state to receive such a large allocation request. A simple solution to this problem is to use palloc_extended() instead of palloc(). But is it safe to allow the checkpointer to allocate so much memory at once? I have proposal to update this memory allocation but I need your ideas and advices on how to do it in appropriate way. As an idea, we can replace the array with a list of arrays to allocate memory in chunks. As a bad idea, we can process a temporary array without locking. I would be glad to hear your ideas and suggestions about this topic. Have a nice day! -- Ekaterina Sokolova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Commits
-
Fix checkpointer shared memory allocation
- 605890034805 17.6 landed
- 7f872ae7020e 13.22 landed
- c5d66fc12b08 14.19 landed
- 73f897ba5836 15.14 landed
- 2ac50f1187c2 16.10 landed
- 5cfbff48a4fd 18.0 landed
- 466c5435fd45 19 (unreleased) landed
-
Limit checkpointer requests queue size
- f32a471612c9 13.22 landed
- 50026136cc86 14.19 landed
- f0cdc2afd15e 16.10 landed
- b248a3ba4e51 15.14 landed
- 13559de95383 17.6 landed
- bae50782170c 18.0 landed
-
Process sync requests incrementally in AbsorbSyncRequests
- 258bf0a2ea8f 19 (unreleased) landed