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:34:17
Message-ID: CA+hUKGJm3Lc97bJSXbcNHtLaPXQw5wVQsAsSRatB7Ae6p-S-QA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 16, 2025 at 3:37 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> while (hand >= NBuffers)
> {
> /* Base value advanced by backend that overshoots by one tick. */
> if (hand == NBuffers)
> pg_atomic_fetch_add_u64(&StrategyControl->ticks_base, NBuffers);
> hand -= NBuffers;
> }

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. I assume it would still
happen occasionally in more than one backend due to the race against
the base advancing a few instructions later, but maybe that'd work out
OK? I dunno. The point would be to make it rare. And with a
per-NUMA-node CLOCK, hopefully quite rare indeed. I guess this way
you don't need to convince yourself that ticks_base is always <= ticks
for all cores, since it would self-correct (if it appears to one core
that ticks_base > ticks then hand will be a very large number and take
this branch). IDK, again untested, just throwing ideas out there...

if (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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2025-08-17 04:39:52 Re: someone else to do the list of acknowledgments
Previous Message jian he 2025-08-17 03:57:50 Re: someone else to do the list of acknowledgments