| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] bufmgr: tighten LWLock:BufferMapping on InvalidateBuffer |
| Date: | 2026-08-11 18:47:11 |
| Message-ID: | hsnzvaqgbcy5z273m3ha773xhvinvdvxbssl6bz67w4spgg2h3@zv77ylqbly5m |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2026-08-11 19:15:48 +0100, Alexandre Felipe wrote:
> While reviewing another thread [1], I noticed a metion to lock duration,
> and I think there is room to improve the current implementation on
> InvalidateBuffer
> and InvalidateVictimBuffer, that thread is already a fork of something else,
> but I think this has its own merit.
>
> In my (current) understanding partition LWLock guards a fraction of the
> hash table
> entries, and the buffer header lock as the name suggests guards the buffer
> descriptor.
> I think holding the Buffer header lock is not a problem,
> as contention would require someone else accessing precisely that buffer,
> holding the partition lock is more critical, as it may contend on thousands
> of
> distinct buffers.
>
> This patch minimises the partition time, and keep the buffer header
> guarding
> the largest portion of the function body.
You absolutely, definitely, never, ever ever may hold a spinlock over
something even remotely as complicated like an lwlock or a hashtable
delete. NEVER.
And without that the patch is completely unsafe.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Corey Huinker | 2026-08-11 19:01:06 | Re: postgres_fdw: Emit message when batch_size is reduced |
| Previous Message | Andres Freund | 2026-08-11 18:31:22 | Re: Crash issue in PG18.5 regression |