From 98e88744ffec806333aa95147aa39ae59af0f0ad Mon Sep 17 00:00:00 2001 From: Michael Quigley Date: Tue, 11 Jun 2024 17:08:24 -0400 Subject: [PATCH] enable_locking (#287) --- .../metrics-and-limits/configuring-limits.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/docs/guides/self-hosting/metrics-and-limits/configuring-limits.md b/docs/guides/self-hosting/metrics-and-limits/configuring-limits.md index 841cb778..eb974847 100644 --- a/docs/guides/self-hosting/metrics-and-limits/configuring-limits.md +++ b/docs/guides/self-hosting/metrics-and-limits/configuring-limits.md @@ -171,6 +171,19 @@ This means that public frontends will simply return a `404` as if the share is n The `accounts` table in the database includes a `limitless` column. When this column is set to `true` the account is not subject to any of the limits in the system. +## Experimental Limits Locking + +zrok versions prior to `v0.4.31` had a potential race condition when enforcing resource count limits. This usually only manifested in cases where shares or environments were being allocated programmatically (and fast enough to win the race). + +This was due to a lack of transactional database locking around the limited structures. `v0.4.31` includes a pessimistic locking facility that can be enabled _only_ on the PostgreSQL store implemention. + +If you're running PostgreSQL for your service instance and you want to enable the new experimental locking facility that eliminates the potential resource count race condition, add the `enable_locking: true` flag to your `store` definition: + +```yaml +store: + enable_locking: true +``` + ## Caveats There are a number of caveats that are important to understand when using the limits agent with more complicated limits scenarios: