storage-postgres: UpdateTable during the DELETING window waits up to 3 s behind the delete poller's lock #556

Summary

On PostgreSQL, an UpdateTable sent during a table's DELETING window can take up to 3 s to be refused. Measured on #550's branch with the window held by a lock on the data table: twelve UpdateTable calls at 0.5 s spacing, ten refused in 2 to 5 ms, two in 1256 ms and 2922 ms. Every answer was the right one (ResourceInUseException, Table is being deleted).

Cause

The delete poller claims the DELETING catalog row FOR UPDATE SKIP LOCKED (crates/storage-postgres/src/worker_store.rs:73) and holds it while its data drop waits out the 3 s lock_timeout. update_table (crates/storage-postgres/src/update_table.rs:99) selects the row FOR UPDATE, so a call that lands during a poller attempt waits for the attempt to time out before it reads the status and refuses.

Fix shape

Read the status with FOR SHARE or without a lock before taking FOR UPDATE, or have the poller release the row lock before the drop attempt. A test that holds the row as the poller does and asserts an UpdateTable refusal under 100 ms.

Found while reviewing #505.