Xlogprefetcher: Use atomic add for increment counter
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t52614psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 09:29 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t52614_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t52614_1 && git checkout t52614_1Patchset v1 (message #1) is on t52614_1
Hi.
Use pg_atomic_fetch_add_u64 to replace pg_atomic_read_u64 and
pg_atomic_write_u64 calls.
This simplifies the logic and this increases the likelihood that the
operation will be successful.
patch attached.
best regards,
Ranier Vilela
Hi,
On 2025-11-07 11:28:06 -0300, Ranier Vilela wrote:
Use pg_atomic_fetch_add_u64 to replace pg_atomic_read_u64 and
pg_atomic_write_u64 calls.This simplifies the logic and this increases the likelihood that the
operation will be successful.
How does it do so? As the assertions indicate, this can only be run from a
single process.
Greetings,
Andres Freund
Em sex., 7 de nov. de 2025 às 11:41, Andres Freund <andres@anarazel.de>
escreveu:
Hi,
On 2025-11-07 11:28:06 -0300, Ranier Vilela wrote:
Use pg_atomic_fetch_add_u64 to replace pg_atomic_read_u64 and
pg_atomic_write_u64 calls.This simplifies the logic and this increases the likelihood that the
operation will be successful.How does it do so? As the assertions indicate, this can only be run from a
single process.
Can I rephrase that?
That simplifies the logic a bit.
best regards,
Ranier Vilela
On 2025-11-07 11:52:37 -0300, Ranier Vilela wrote:
Em sex., 7 de nov. de 2025 �s 11:41, Andres Freund <andres@anarazel.de>
escreveu:On 2025-11-07 11:28:06 -0300, Ranier Vilela wrote:
Use pg_atomic_fetch_add_u64 to replace pg_atomic_read_u64 and
pg_atomic_write_u64 calls.This simplifies the logic and this increases the likelihood that the
operation will be successful.How does it do so? As the assertions indicate, this can only be run from a
single process.Can I rephrase that?
That simplifies the logic a bit.
Maybe simpler, but also vastly slower than before. An atomic increment is
maybe two orders of magnitude more expensive than an unlocked read & write.
Em sex., 7 de nov. de 2025 às 11:59, Andres Freund <andres@anarazel.de>
escreveu:
On 2025-11-07 11:52:37 -0300, Ranier Vilela wrote:
Em sex., 7 de nov. de 2025 às 11:41, Andres Freund <andres@anarazel.de>
escreveu:On 2025-11-07 11:28:06 -0300, Ranier Vilela wrote:
Use pg_atomic_fetch_add_u64 to replace pg_atomic_read_u64 and
pg_atomic_write_u64 calls.This simplifies the logic and this increases the likelihood that the
operation will be successful.How does it do so? As the assertions indicate, this can only be run
from a
single process.
Can I rephrase that?
That simplifies the logic a bit.
Maybe simpler, but also vastly slower than before. An atomic increment is
maybe two orders of magnitude more expensive than an unlocked read & write.
Seriously, I didn't know.
It's best to withdraw the patch then.
Thanks for clarifying this.
best regards,
Ranier Vilela