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