When every replica receives the same schedule, the database can arbitrate a single active owner without another coordination service.
Session-Bound Job Exclusion
Mutual exclusion is useful only while ownership remains bound to one live session.
SELECT pg_try_advisory_lock($1::int, $2::int) AS acquired;
-- Exit cleanly when acquired = false.
-- Run work on this dedicated database session inside try/finally.
SELECT pg_advisory_unlock($1::int, $2::int);Invariant: Only one database session owns the job at a time.
Use when: A scheduled job may start on many replicas but only one should execute.
Why this boundary matters
Session loss releases ownership automatically, which prevents permanent locks but means external side effects must remain restartable and reconcilable.
Failure policy
| Boundary | Action |
|---|---|
| Lock acquired | Run the job on that same database session |
| Lock unavailable | Exit successfully; another replica owns the run |
| Database session lost | Assume ownership is lost and stop work |
| Job exceeds its schedule | Keep one owner and alert on runtime |
| Connection pool may swap sessions | Use a dedicated connection or transaction-scoped design |
Trade-offs
Advisory locks avoid another coordinator but couple job liveness to PostgreSQL and provide no durable job state. A lock prevents overlap; it does not provide retries, progress checkpoints, or recovery of external side effects.
Decision rule: Use an advisory lock for short, restartable single-flight work whose natural coordination boundary is PostgreSQL.