| From: | Ekaterina Sokolova <e(dot)sokolova(at)postgrespro(dot)ru> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Proposal: Limitations of palloc inside checkpointer |
| Date: | 2025-02-25 19:44:33 |
| Message-ID: | db4534f83a22a29ab5ee2566ad86ca92@postgrespro.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2025-02-25 20:05:22 | Re: Trigger more frequent autovacuums of heavy insert tables |
| Previous Message | Maksim.Melnikov | 2025-02-25 19:34:32 | Spinlock can be released twice in procsignal.c |