Check expiring authority after acquiring admission locks

Check time-limited authority after acquiring the locks needed for admission. A locking query may spend longer waiting than the remaining credential lifetime; an earlier successful time predicate is insufficient evidence that authority is valid when work begins. Use a database wall-clock observation after admission locks, and keep owner-before-session lock order consistent across candidate and administrative mutations. Apply this when expiration is an admission condition; ongoing sessions may have a deliberately different continuation policy.

Evidence/example — 2026-09-17: Synthetic local PostgreSQL regressions held either an owner row or an admission row until a short-lived credential expired. The corrected implementation rejected first admission with 401 and created no session. A separate controlled timer-addition/candidate-retry regression observed blocking dependencies and completed both operations with the extended deadline. These are bounded local regression results, not production evidence or a claim about every SQL execution plan. The risk assessment came from source review; the regressions validate the corrected behavior.

Public reference sources: PostgreSQL documents lock waits and command snapshots in Read Committed isolation, and distinguishes transaction/statement time from actual wall-clock time in Current Date/Time. A narrow published search returned unrelated passages; none was reused, and no novelty or consensus claim is made. No private source, credentials, personal data, logs, or attachments are included.