db

const AuditChainLockKey int64 = 0x5741524459_434841 // ASCII "WARDYCHA"

AuditChainLockKey serializes appends to the audit_events hash chain (migration 0047). Unlike every key above it is taken with the TRANSACTION -scoped pg_advisory_xact_lock, never the session-scoped form: it is released by the commit that makes the new row visible, so the next writer's head read cannot miss it, and no code path can leak it by forgetting a release. It must be taken BEFORE the INSERT statement, on the inserting transaction — not inside 0047's BEFORE INSERT trigger, where the identity default has already assigned seq and two racing writers could invert chain order against seq order. Both in-tree insert paths do this: store.InsertAuditEvent and the broker's insertAuditEventTx. ponytail: ONE lock for the whole chain, so audit appends are globally serialized. That IS the feature (a chain has exactly one head), and audit write volume is nowhere near a contention regime. If it ever is, the upgrade is per-partition chains with a key per partition, not a finer lock over one.

const GroundTruthRotatorLockKey int64 = 0x5741524459_475452 // ASCII "WARDYGTR"

GroundTruthRotatorLockKey elects the ground-truth token rotator's leader across control planes (S2). Unlike ReaperAdvisoryLockKey (re-tried every tick via TryAdvisoryLock, release()d at the end of each one), this key is acquired ONCE before the rotator's loop starts and held for the process lifetime: only the holder mints/writes the shared token file, and every other replica parks on a backoff and retries, taking over automatically when the holder's Postgres session ends.

It buys AT MOST ONE STEADY-STATE leader, NOT mutual exclusion. An advisory lock dies with its SESSION, not with the process, and the holder never re-verifies it: a Postgres restart, a failover, pg_terminate_backend or an idle-session timeout releases it under a still-running leader, and a standby takes over within one backoff — two rotators, neither aware. Harmless for THIS workload only, because every write is an atomic rename of a stateless token (cmd/wardynd/gt_rotator.go). Work that needs genuine fencing must not reuse this key. Any stable value works, as long as it differs from every other key in this file.

const ReaperAdvisoryLockKey int64 = 0x5741524459_524541 // ASCII "WARDYREA"

ReaperAdvisoryLockKey makes the lifecycle reap tick single-flight across control planes. Unlike migrateAdvisoryLockKey (a BLOCKING lock — the second boot must still see the migrations applied), this one is only ever taken with TryAdvisoryLock: a replica that loses SKIPS the tick, because a queued second reap of the same runs is pure duplicate work and a duplicate run.autostop.

const SecretRekeyLockKey int64 = 0x5741524459_524B59 // ASCII "WARDYRKY"

SecretRekeyLockKey serializes the `wardynd -rotate-age-key` maintenance mode (cmd/wardynd's rotateAgeKeyMode): two concurrent rekeys of the same store would each re-encrypt from an old key the other has already replaced, so the second is refused rather than queued (TryAdvisoryLock, like ReaperAdvisoryLockKey).

HONEST CEILING — this does NOT detect a running wardynd. No wardynd holds a process-lifetime lock on this key or any other unconditional one (the reaper takes ReaperAdvisoryLockKey per tick and releases it; GroundTruthRotatorLockKey is only taken when the rotator is configured), so a serving daemon is invisible to this check. "Stop the daemon first" is an operator procedure documented in docs/OPERATIONS.md, not something this lock enforces — a live daemon holds the OLD identity in memory and would write ciphertext under a key the rekey has already retired.