Throwing away unnecessary spin-locks

From: Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Throwing away unnecessary spin-locks
Date: 2026-10-01 19:50:35
Message-ID: CAE8JnxPcmZVDkf39Pa=uBGcVacsm6OkGxYigp6Znxu=Z3_DE7w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi All,

Please try, if you want
$ grep -A 2 -rn SpinLockAcquire src/backend | grep SpinLockRelease -B 2

Story
=====
A common pattern that I have been repeatedly warned against is using
spin-locks unnecessarily. I was surprised to see in checkpointer.c
FirstCallSinceLastCheckpoint.

int new_done;
SpinLockAcquire(&CheckpointerShmem->ckpt_lck);
new_done = CheckpointerShmem->ckpt_done;
SpinLockRelease(&CheckpointerShmem->ckpt_lck);

I think could certainly be replaced by something like

+ pg_compiler_barrier()
+ new_done = CheckpointerShmem->ckpt_done;
+ pg_compiler_barrier()

Grepping the codebase we get
105 matches, in 26 files.

One interesting case is xlog.c that uses the lock to protect 64-bit
assignments
I saw conversations about pg_atomic_u64 for that, but then in 32-bit
platforms
we get this weird 3-field structure everywhere.

Regards,
Alexandre

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Lakhin 2026-10-01 20:00:00 Re: Improving tracking/processing of buildfarm test failures
Previous Message Jelte Fennema-Nio 2026-10-01 19:48:47 Re: Commitfest PG20-2 is now closed