remove adaptive spins_per_delay code

(creating new thread from [0])

On Wed, Apr 10, 2024 at 09:52:59PM -0400, Tom Lane wrote:
> On fourth thought ... the number of tries to acquire the lock, or
> in this case number of tries to observe the lock free, is not
> NUM_DELAYS but NUM_DELAYS * spins_per_delay. Decreasing
> spins_per_delay should therefore increase the risk of unexpected
> "stuck spinlock" failures. And finish_spin_delay will decrement
> spins_per_delay in any cycle where we slept at least once.
> It's plausible therefore that this coding with finish_spin_delay
> inside the main wait loop puts more downward pressure on
> spins_per_delay than the algorithm is intended to cause.
>
> I kind of wonder whether the premises finish_spin_delay is written
> on even apply anymore, given that nobody except some buildfarm
> dinosaurs runs Postgres on single-processor hardware anymore.
> Maybe we should rip out the whole mechanism and hard-wire
> spins_per_delay at 1000 or so.

I've been looking at spinlock contention on newer hardware, and while I do
not yet have any proposal to share for that, I saw this adaptive
spins_per_delay code and wondered about this possibility of "downward
pressure on spins_per_delay" for contended locks. ISTM it could make
matters worse in some cases.

Anyway, I'm inclined to agree that the premise of the adaptive
spins_per_delay code probably doesn't apply anymore, so here's a patch to
remove it.

[0] https://postgr.es/m/65063.1712800379%40sss.pgh.pa.us

--
nathan