Re: [PATCH] Let's get rid of the freelist and the buffer_strategy_lock

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Greg Burd <greg(at)burd(dot)me>
Cc: Tomas Vondra <tomas(at)vondra(dot)me>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Let's get rid of the freelist and the buffer_strategy_lock
Date: 2025-08-17 04:57:29
Message-ID: CA+hUKG+LxEPeFdgf22MS9PqB_xsTFNGigkXY2Nd=3cb1sVt-5w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Aug 17, 2025 at 4:34 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> Or if you don't like those odds, maybe it'd be OK to keep % but use it
> rarely and without the CAS that can fail.

... or if we wanted to try harder to avoid %, could we relegate it to
the unlikely CLOCK-went-all-the-way-around-again-due-to-unlucky-scheduling
case, but use subtraction for the expected periodic overshoot?

if (hand >= NBuffers)
{
hand = hand < Nbuffers * 2 ? hand - NBuffers : hand % NBuffers;
/* Base value advanced by backend that overshoots by one tick. */
if (hand == 0)
pg_atomic_fetch_add_u64(&StrategyControl->ticks_base, NBuffers);
}

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-08-17 06:19:03 Re: Remove Instruction Synchronization Barrier in spin_delay() for ARM64 architecture
Previous Message Corey Huinker 2025-08-17 04:39:52 Re: someone else to do the list of acknowledgments