Skip to content
Atlas

Atlas 0.5.1

Released 2026-10-19 · v0.5.1 on GitHub · install with "atlas": "github:AndreyDAraya/atlas#v0.5.1"

A held hot row no longer stalls a whole instance. Found by the MallFeed backend stress audit (R2): one session holding a product’s stock record for 30 s cut API throughput by 92%, because every command on it waited the connection’s lock_timeout (3 s) per attempt while holding a pool client, and those commands filled the pool.

Changed

Section titled “Changed”
  • Command commits wait at most 200 ms for a row lock. A dispatch’s commit sets SET LOCAL lock_timeout (in the same round trip as BEGIN); a record it expects that another session still holds after that is a conflict (55P03), retried with the jittered wait up to retry.attempts times, then answered conflict { attempts }, instead of a thrown store error after the connection’s whole timeout. Configure with createPostgresStore(pool, { commandLockTimeoutMs }) (0 keeps the connection’s timeout). Delivery and rebuild commits keep the connection’s lock_timeout: workers run one batch per consumer on their own pool, and their waits are mostly a concurrent advance of the same cursor.
  • Records a commit only read are locked FOR SHARE. Expected records the commit writes or removes stay FOR UPDATE; the others take a share lock, which still blocks a concurrent writer (the version cannot change before the commit ends) but lets commits that read the same record (a store, a plan) proceed side by side instead of queueing. Without it, the short command lock timeout above turned that queue into conflicts (50 concurrent checkouts of one product: 14 retries).

From CHANGELOG.md. All versions: Releases.