Possible optimization of heap_lock_tuple()
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:t44286psql -h localhost -U postgresBuilt from patchset v1 (message #1), August 24, 2026 at 11:27 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 t44286_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 t44286_1 && git checkout t44286_1Patchset v1 (message #1) is on t44286_1
It seems that a concurrent UPDATE can restart heap_lock_tuple() even if it's
not necessary. Is the attached proposal correct and worth applying?
--
Antonin Houska
Web: https://www.cybertec-postgresql.com