extern/zrok
1
1
Fork 0
mirror of https://github.com/openziti/zrok.git synced 2024-11-07 08:44:14 +01:00
Code Issues Packages Projects Releases Wiki Activity

enable_locking (#287)

Browse Source
This commit is contained in:
Michael Quigley 2024-06-11 17:08:24 -04:00
parent 2d944e965a
commit 98e88744ff
No known key found for this signature in database
GPG Key ID: 9B60314A9DD20A62
1 changed files with 13 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
docs/guides/self-hosting/metrics-and-limits/configuring-limits.md
View File

@ -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: