PostgreSQL: DeleteTable's first catalog select has no lock timeout and waits behind CreateBackup
I maintainer di solito rispondono entro 2 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
Direzione di ricerca
Read crates/storage-postgres/src/delete_table.rs around the initial FOR UPDATE select, then inspect the FOR SHARE rationale in crates/storage-postgres/src/backup_engine.rs and the timeout handling from PR #504 in worker_store.rs. First measure how DynamoDB handles DeleteTable during CreateBackup, as the issue says this behavior has not been re-measured. Add a test that holds the row FOR SHARE on a second connection; done means DeleteTable returns within the timeout with the response matching the measured service behavior.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Where
crates/storage-postgres/src/delete_table.rs, the SELECT ... FROM tables WHERE account_id = $1 AND table_name = $2 AND table_status IN ('ACTIVE', 'CREATING') FOR UPDATE that starts every DeleteTable, on main at abf8082f (lines 27 to 41).
What happens
The select runs on a catalog transaction with no lock_timeout. It waits for any transaction that holds the table's row:
CreateBackupholds the rowFOR SHAREfrom its first catalog read until the data snapshot has been taken (crates/storage-postgres/src/backup_engine.rs, the comment above theFOR SHAREselect explains why), so a DeleteTable issued during a backup of a large table waits for the whole snapshot.UpdateTableholds the rowFOR UPDATEfor the length of its catalog transaction (crates/storage-postgres/src/update_table.rs).
While it waits, the request holds one connection of the catalog pool. With pool_size concurrent DeleteTable calls against tables being backed up, the pool is exhausted for other requests until the backups finish or sqlx's 30 s acquire timeout fires for the later callers.
The same shape was bounded for the control-plane pass in PR #504 (a transaction-local lock_timeout on the catalog transaction, and a defined answer when it fires). This select was left as it was because it is on main and not part of that fix.
Service behaviour
On Amazon DynamoDB, DeleteTable during a CreateBackup of the same table answers 200 with TableStatus: DELETING and the backup completes (the backup is of the table state at request time). This was not re-measured for this issue; the row for it should be measured before the fix is written.
Suggested fix
Set a transaction-local lock_timeout on the DeleteTable catalog transaction before the select (the constant PR #504 introduces in worker_store.rs can move to a shared place). On lock_not_available, decide the answer from the measurement: if the service serves the delete during a backup, the fix is to not block on the backup's FOR SHARE at all (for example by reading the row without the lock and marking it DELETING with a conditional UPDATE, letting the backup's definition read stay consistent through its own snapshot); otherwise answer ResourceInUseException with the measured sentence.
A test: hold the row FOR SHARE from a second connection, call DeleteTable, expect it to return within the timeout rather than wait for the release.
- Lingua principale
- Rust
- Stelle
- 517
- Fork
- 60
- Merge medio
- 2g 23h
- PR unite (30g)
- 25
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ExtendDB/extenddb
-
backend:mongodb bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
I maintainer di solito rispondono entro 2 giorni
-
backend:cassandra bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 2 giorni
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 2 giorni
-
backend:cassandra bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 2 giorni
-
[storage.cassandra] accepts unknown keys silentlyForse già presa @LeeroyHannigan l’ha presa 2 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
ExtendDB/extenddb#540 · 1 assegnatario ·
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di ExtendDB/extenddb
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
dsx-ai-factory/infra-controller#8341 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement triage:deciding
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
open-telemetry/otel-arrow#4540 ·
I maintainer di solito rispondono entro 2 giorni
-
benchmark: CSV report files contain blank records on WindowsForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertacomponent:benchmark
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
agentic-os-org/ANOLISA#9177 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
oracle/rust-oracledb#61 ·
-
bug priority-medium to-agent
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno