-
Improvement
-
Resolution: Fixed
-
Minor
-
3.7.3, 3.8, 3.9
-
MOODLE_37_STABLE, MOODLE_38_STABLE, MOODLE_39_STABLE
-
MOODLE_39_STABLE
-
MDL-65722-no-lock-db -
The postgres advisory locks works with an integer, but the moodle lock API works with a string. So the postgres impl re-uses the mdl_lock_db table to manage this mapping:
https://github.com/moodle/moodle/blob/master/lib/classes/lock/postgres_lock_factory.php#L144-L156
This impl made some sense back when the number of resource keys was discrete, and essentially limited to just the names of scheduled tasks.
Now I don't think this makes any sense, there are lots of ad hocs tasks and other clients of the Lock API which are single use (eg objectfs leverages this heaps). In our largest client we have 10's of million rows in mdl_lock_db and it is all junk.
So I'm proposing to eliminate the db lookup and polling and convert this to a deterministic fast hash, eg something like string -> md5 / sha256 -> truncate to N chars -> convert to integer that fits inside a postgres bigint
https://www.postgresql.org/docs/current/datatype-numeric.html
bigint | 8 bytes | large-range integer | -9223372036854775808 to 9223372036854775807 |
And an upgrade task to truncate that table as needed