| From: | Xuneng Zhou <xunengzhou(at)gmail(dot)com> |
|---|---|
| To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Maxim Orlov <orlovmg(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Ekaterina Sokolova <e(dot)sokolova(at)postgrespro(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Proposal: Limitations of palloc inside checkpointer |
| Date: | 2025-06-04 12:33:30 |
| Message-ID: | CABPTF7XG_TcoSiEUb4GHKeX4ugaU4Pd9Q6CukJcOJVtOFhFOHg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Thanks for the feedback!
> I think it would be good start point to use the same batch size of
> CompactCheckpointerRequestQueue() and AbsorbSyncRequests()
>
So we’ll keep both batch processing and the request cap in place for now.
> > > Right, but another point is to avoid lengthy holding of
> > > CheckpointerCommLock. What do you think about that?
> >
> > I am not clear on this. Could you elaborate on it?
>
> See [1] for more detailed description of this.
> Links.
> 1. https://www.postgresql.org/message-id/flat/db4534f83a22a29ab5ee2566ad86ca92%40postgrespro.ru
I read the thread but didn’t find a specific explanation of avoiding
long lock holds. My understanding is: when compaction processes a very
large queue in one go, it holds CheckpointerCommLock the entire time,
blocking all ForwardSyncRequest callers. Batch processing would
release the lock after each chunk, allowing other backends to make
progress. Is that correct?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrei Lepikhov | 2025-06-04 12:52:04 | Re: MergeAppend could consider sorting cheapest child path |
| Previous Message | Andy Fan | 2025-06-04 12:10:06 | Some questions about gin index |