News for hackers. Stuff that matters.
Re:Pglocks.org by atombender on Sunday May 18, 2025 @05:46AM (#44020181)
The creator looks like a developer and teacher, not a Postgres core team member. So I assume this is for documentation purposes.

I actually like this a lot, as there isn't a single place in the Postgres documentation that lists all the possible locks; it's spread out all over. Having a quick reference for what kinds of commands you'd be blocking with your transaction is valuable.

It's pretty evident that the pages have been programmatically generated, but I'd love know what it's generated from. I think you can derive this information from the documentation, but not sure if you can do it in an automated way without an LLM.

Re:Pglocks.org by braiamp on Sunday May 18, 2025 @05:49AM (#44020201)
> there isn't a single place in the Postgres documentation that lists all the possible locks

Did you read this page? https://www.postgresql.org/docs/current/explicit-locking.htm...

Re:Pglocks.org by atombender on Sunday May 18, 2025 @06:03AM (#44020236)
That's a great page, but it has several issues.

First, it isn't complete; as I said, the locking behaviour is spread out all over the Postgres documentation. For example, that page doesn't list what locks DROP INDEX takes. To find that out, you have to go to the documentation page for that command and read it carefully. In fact, really carefully — the locking behaviour is only documented under the section about CONCURRENTLY.

The page also doesn't list what possible commands are then blocked. Locks interact in subtle (and incorrectly named!) ways that are explained in the tables on that page ("Conflicting lock modes"), so to understand if something will block something else you have to look at the two commands you are curious about and then look at how their locks interact.

Re:Pglocks.org by gulcin_xata on Monday May 19, 2025 @06:47AM (#44028370)
I agree, it is not so straightforward to find out.