Locking is a challenging problem in complex systems. Is this list to be interpreted as a "TODO: get rid of locking conflicts in future releases" or more a "NOTE: be aware there are known conflicts that will not change - find ways to work around them"?
EDIT: Also, is the creation of this list an automated or a manual effort?
braiamp · 19m ago
These are database locks, which means that depending which arrives first, the later transaction has to wait till the first one finishes to complete. These locks are about SQL commands and which commands can run concurrently with the others. There's a graph here of how that looks like https://pankrat.github.io/2015/django-migrations-without-dow...
Usually for maximum performance (minimum latency, maximum throughput) you want to have operations not lock each other, unless absolutely necessary, in which case you want them to be short.
atombender · 20m ago
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.
braiamp · 17m ago
> there isn't a single place in the Postgres documentation that lists all the possible locks
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.
tux3 · 23m ago
I think this is intended as educational material, not a list of things to fix.
The locks are here by necessity, it is not so easy at all to get rid of them. And even in special cases where it is possible, the complexity you have to introduce is not to be taken lightly...
If even a tenth of these disapppeared, it would be incredible, in a very surprising way.
Locking is a challenging problem in complex systems. Is this list to be interpreted as a "TODO: get rid of locking conflicts in future releases" or more a "NOTE: be aware there are known conflicts that will not change - find ways to work around them"?
EDIT: Also, is the creation of this list an automated or a manual effort?
Usually for maximum performance (minimum latency, maximum throughput) you want to have operations not lock each other, unless absolutely necessary, in which case you want them to be short.
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.
Did you read this page? https://www.postgresql.org/docs/current/explicit-locking.htm...
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.
The locks are here by necessity, it is not so easy at all to get rid of them. And even in special cases where it is possible, the complexity you have to introduce is not to be taken lightly...
If even a tenth of these disapppeared, it would be incredible, in a very surprising way.