| From: | Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | [PATCH] bufmgr: tighten LWLock:BufferMapping on InvalidateBuffer |
| Date: | 2026-08-11 18:15:48 |
| Message-ID: | CAE8JnxOR9cJtXGG-3Ki33zHyh5oEcuVeRqeToEvu-44T+R-DnA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
[1]
https://www.postgresql.org/message-id/dbbd1998-19ff-4ac2-b4b1-a39f4ec1b0f5%40iki.fi
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-buffmgr-Tighten-LWLock-BuferMapping.patch | application/octet-stream | 5.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2026-08-11 18:26:02 | Re: Crash issue in PG18.5 regression |
| Previous Message | Ayush Tiwari | 2026-08-11 18:05:08 | Re: Error handling in after-startup shmem requests |