Message-ID: <1108f18d-cf7c-4f17-b29c-a119fe42f7e5@iki.fi>
Date: Thu, 18 Dec 2025 19:20:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
To: Andres Freund <andres@anarazel.de>
Cc: Melanie Plageman <melanieplageman@gmail.com>,
 Matthias van de Meent <boekewurm+postgres@gmail.com>,
 pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@gmail.com>,
 Noah Misch <noah@leadboat.com>, Robert Haas <robertmhaas@gmail.com>,
 Michael Paquier <michael.paquier@gmail.com>
References: <pmto7djq64mei53p7r5smfync2waittilhbuzc7j7lpflf2b3y@laz7r76y5pux>
 <CAEze2WjeK9CY003S4dmCugv_H4tz9AaXgnqW+wTc=BaPDg+2xg@mail.gmail.com>
 <3je3ahgf7rrmmurxo6hnlhg5d3ffwfrtjwjxd6jm5srlv5iebp@vxqk5qtgmowr>
 <3w7v3w6a57jnssokap4k7thoekig72flnyhd4wp3yftzdd7lm7@f6lpcfen6hr7>
 <6rgb2nvhyvnszz4ul3wfzlf5rheb2kkwrglthnna7qhe24onwr@vw27225tkyar>
 <CAAKRu_ZcZCXNUWfhEg4qOYuRO8T1x3_gvaUFFrwgCfY0RnVhkg@mail.gmail.com>
 <3nce7i72ayzkunai6mkz24ckbxk74jodz4ua2chcdrwppxlxcd@w6x5kfkjrkru>
 <lneuyxqxamqoayd2ntau3lqjblzdckw6tjgeu4574ezwh4tzlg@noioxkquezdw>
 <c00d4a9f-c0f8-49ca-bf27-29c6641f2fc6@iki.fi>
 <q3ybyaiownp4ivt6xfy55s5llvtq6vqsd4zbt5kn6hacxdcpp4@2ngd4h4bev5d>
 <dsbacri4xldlobl3jbqqlksefsyrwj7lzljbohxsbqjus3z4o7@otb6rge4w7az>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <dsbacri4xldlobl3jbqqlksefsyrwj7lzljbohxsbqjus3z4o7@otb6rge4w7az>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/1108f18d-cf7c-4f17-b29c-a119fe42f7e5%40iki.fi>
Precedence: bulk

On 18/12/2025 19:03, Andres Freund wrote:
> Hi,
> 
> On 2025-12-17 09:54:32 -0500, Andres Freund wrote:
>> On 2025-12-17 11:25:50 +0200, Heikki Linnakangas wrote:
>>> - LWLockWaitListLock() uses pg_atomic_read_u32() after spinning,
>>> LockBufHdr() retries directly with pg_atomic_fetch_or_u32().
>>
>> I think here LWLockWaitListLock() is likely right - but it seems like a change
>> to LockBufHdr() that I would probably make in a separate commit?
> 
> FWIW, I couldn't come up with a scenario where it makes a performance
> difference - exclusive content locks just aren't *that* frequent. And because
> of that the wait list lock doesn't have similar contention as some non-content
> lwlocks (like XidGenLock). The most extreme workload I could think of was
> pgbench hammering a single sequence across many sessions. While the exclusive
> locks show up in wait events, the buffer header spinlock itself doesn't..
> 
> So I'm inclined to not change anything about this for now.

Ok. My thinking was just that LockBufHdr() and LWLockWaitListLock() 
should be consistent with each other. Otherwise anyone reading the code 
will ask the question "why are they different?". They're the only two 
things using the spin delay mechanism in our codebase, in addition to 
actual spinlocks.

BTW, I wonder if it would be worthwhile to have an inlineable fast-path 
of LockBufHdr() for the common case that the lock is free? I see that 
UnlockBufHdr() is already a static inline function.

- Heikki