Re: Proposal: Limitations of palloc inside checkpointer - Mailing list pgsql-hackers

From Maxim Orlov
Subject Re: Proposal: Limitations of palloc inside checkpointer
Date
Msg-id CACG=ezZJGhJgZEKc3arPFKMUWjmXLFt_GeaMTqXcMxQPfR31jg@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: Limitations of palloc inside checkpointer  (Maxim Orlov <orlovmg@gmail.com>)
List pgsql-hackers
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.
Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Add -k/--link option to pg_combinebackup
Next
From: vignesh C
Date:
Subject: Re: pg_dump, pg_dumpall, pg_restore: Add --no-policies option