Re: [PATCH] bufmgr: tighten LWLock:BufferMapping on InvalidateBuffer - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [PATCH] bufmgr: tighten LWLock:BufferMapping on InvalidateBuffer
Date
Msg-id hsnzvaqgbcy5z273m3ha773xhvinvdvxbssl6bz67w4spgg2h3@zv77ylqbly5m
Whole thread
Responses Re: pg_stat_replication docs incomplete for logical replication
List 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



Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Crash issue in PG18.5 regression
Next
From: Corey Huinker
Date:
Subject: Re: postgres_fdw: Emit message when batch_size is reduced