Horton

Re: Proposal: Limitations of palloc inside checkpointer

Maxim Orlov <orlovmg@gmail.com>

View thread View on postgr.es
From: Maxim Orlov <orlovmg@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Ekaterina Sokolova <e.sokolova@postgrespro.ru>, pgsql-hackers@lists.postgresql.org
Date: 2025-02-27T14:16:28Z
Lists: pgsql-hackers

Attachments

I tried to implement the idea (4). This is the patch.

But, there is a problem. See, when we release lock and call
RememberSyncRequest() and acquire it again,
CompactCheckpointerRequestQueue() may be called and the state of the
request array may be changed. Of course, we can recheck num_requests after
retaking the lock and restart the algo all over again. But this is not a
great idea, since we can stuck in this loop if someone is pushing requests
in the queue.

As for case (3). In fact, the described problem happens only with high
enough values of NBuffers. Thus, user already expected postgres to use huge
amount of RAM. Is this really a problem if he will demand some more to
process sync request?

-- 
Best regards,
Maxim Orlov.

Commits

  1. Fix checkpointer shared memory allocation

  2. Limit checkpointer requests queue size

  3. Process sync requests incrementally in AbsorbSyncRequests