| From: | Maxim Orlov <orlovmg(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Ekaterina Sokolova <e(dot)sokolova(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Proposal: Limitations of palloc inside checkpointer |
| Date: | 2025-02-27 14:16:28 |
| Message-ID: | CACG=ezZJGhJgZEKc3arPFKMUWjmXLFt_GeaMTqXcMxQPfR31jg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 | Content-Type | Size |
|---|---|---|
| v1-0001-AbsorbSyncRequests-incrementally-instead-of-doing.patch | application/octet-stream | 3.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2025-02-27 14:37:38 | Re: pg_dump, pg_dumpall, pg_restore: Add --no-policies option |
| Previous Message | Robert Haas | 2025-02-27 14:04:03 | Re: Add -k/--link option to pg_combinebackup |