mirror of
https://codeberg.org/forgejo/forgejo.git
synced 2026-07-12 20:48:40 +00:00
a85d9b2b52
This is a monster transaction, it touches a lot of tables and happily locks many rows which results in all other operations waiting on this transaction to finish. In a lot of cases this operation is fast and for many this wouldn't be a problem, however on Codeberg we've observed that when large (many issues, comments and PRs specifically) repository is being deleted it can result in the instance being unreachable to do any other modification to it. This is not fixable for SQLite (although if you get such large repositories and has many concurrent writes, then maybe SQLite is no longer a good choice) as transactions are always of the SERIALIZABLE level. PostgreSQL default isolation level is READ COMMITTED and seems to me the observed behavior on Codeberg wouldn't happen here unless the default isolation level is to be made REPEATABLE READ or SERIALIZABLE. MySQL/MariaDB default isolation level is REPEATABLE READ and that gets the behavior of rows being locked (even those that aren't being modified). And this is where this patch is effective to make this transaction a bit less of a monster. There's a small risk of making this transaction READ COMMITTED, there's a window where new records can be created for this repository which will then not be deleted. These will eventually be solved by foreign keys, currently most can still be removed after the fact by the `check-db-consistency` doctor check. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12856 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> |
||
|---|---|---|
| .. | ||
| TestDeleteOrganization | ||
| org.go | ||
| org_test.go | ||
| repo.go | ||
| repo_test.go | ||
| team_invite.go | ||
| team_invite_test.go | ||