Re: [PATCH] bufmgr: tighten LWLock:BufferMapping on InvalidateBuffer

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

In response to

Responses

Browse pgsql-hackers by date

  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