Re: [PATCH] Let's get rid of the freelist and the buffer_strategy_lock - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: [PATCH] Let's get rid of the freelist and the buffer_strategy_lock
Date
Msg-id CA+hUKGJm3Lc97bJSXbcNHtLaPXQw5wVQsAsSRatB7Ae6p-S-QA@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Let's get rid of the freelist and the buffer_strategy_lock  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: [PATCH] Let's get rid of the freelist and the buffer_strategy_lock
List pgsql-hackers
On Sat, Aug 16, 2025 at 3:37 PM Thomas Munro <thomas.munro@gmail.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);
    }



pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: someone else to do the list of acknowledgments
Next
From: Corey Huinker
Date:
Subject: Re: someone else to do the list of acknowledgments