(docs): add missing info about ShareLocks
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:t77905psql -h localhost -U postgresBuilt from patchset v3 (message #3), September 20, 2026 at 09:21 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 t77905_3 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 t77905_3 && git checkout t77905_3Patchset v3 (message #3) is on t77905_3
Hello
I had a production incident a few weeks ago while using deferred indexes, where the Postgres docs lead me down the wrong path of investigation due to missing details. Specifically, the docs implied that a `ShareLock` was only acquired when creating indexes, but only after looking at the code did I learn that this lock is also acquired when transactions are waiting for other transactions to complete. I think this would be helpful to someone who might find themselves on the same path in the future, and as I understand it this mailing list is the way to submit patches to the docs?
Attachments:
0001-document-ShareLock-behaviour-when-using-a-deferred-u.patchapplication/octet-stream; name=0001-document-ShareLock-behaviour-when-using-a-deferred-u.patch; x-unix-mode=0644Download+5-1
On Sat, 2025-11-22 at 09:07 +0100, Alpha Shuro wrote:
I had a production incident a few weeks ago while using deferred indexes, where
the Postgres docs lead me down the wrong path of investigation due to missing details.
Specifically, the docs implied that a `ShareLock` was only acquired when creating
indexes, but only after looking at the code did I learn that this lock is also
acquired when transactions are waiting for other transactions to complete.
I think this would be helpful to someone who might find themselves on the same path
in the future, and as I understand it this mailing list is the way to submit patches
to the docs?
No, that is wrong. This section is about table locks, and a lock on a transaction ID
should, if anywhere, be documented elsewhere. Actually, there is already something
about transaction ID locks in https://www.postgresql.org/docs/current/xact-locking.html
Perhaps you could improve that short documentation?
Yours,
Laurenz Albe
PS: There are also SHARE locks on rows.
Ah thanks for pointing this out, I've moved it to the xact-locking page instead
On Thu, 2025-11-27 at 12:33 +0100, Alpha Shuro wrote:
Ah thanks for pointing this out, I've moved it to the xact-locking page instead
I think that is too specific. You can see a session waiting for a SHARE
lock on a transaction whenever it is waiting for a row lock, since row
locks are not permanently stored in the shared memory lock table.
Rather than adding a paragraph about the specific incident that happened
to you, you should describe the general mechanism.
Some reading material:
https://www.cybertec-postgresql.com/en/row-locks-in-postgresql/
Yours,
Laurenz Albe