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.
v1-0001-AbsorbSyncRequests-incrementally-instead-of-doing.patch
Description: Binary data
