{"record":{"id":"84e19b6ac43329e3","repo":"multica-ai/multica","slug":"acquire-advisory-lock-d-w","errorCode":null,"errorMessage":"acquire advisory lock %d: %w","messagePattern":"acquire advisory lock (.+?): %w","errorType":"console","errorClass":null,"httpStatus":null,"severity":"error","filePath":"server/cmd/backfill_codex_usage_cache/main.go","lineNumber":119,"sourceCode":"\t\treturn err\n\t}\n\tlogSummary(cfg, rows, total)\n\tif total.Rows == 0 {\n\t\tslog.Info(\"no eligible Codex task_usage rows found\")\n\t\treturn nil\n\t}\n\tif !cfg.execute {\n\t\tslog.Info(\"dry-run complete; review the summary, then re-run with --execute to apply the backfill\")\n\t\treturn nil\n\t}\n\n\tlockConn, err := pool.Acquire(ctx)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"acquire advisory-lock connection: %w\", err)\n\t}\n\tdefer lockConn.Release()\n\tif _, err := lockConn.Exec(ctx, `SELECT pg_advisory_lock($1)`, rollupAdvisoryLockID); err != nil {\n\t\treturn fmt.Errorf(\"acquire advisory lock %d: %w\", rollupAdvisoryLockID, err)\n\t}\n\tdefer func() {\n\t\t_, _ = lockConn.Exec(context.Background(), `SELECT pg_advisory_unlock($1)`, rollupAdvisoryLockID)\n\t}()\n\n\tupdateStartedAt, err := databaseClock(ctx, pool)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tupdatedRows, removedTokens, err := executeBackfill(ctx, pool, cfg)\n\tif err != nil {\n\t\treturn err\n\t}\n\tslog.Info(\"task_usage rows updated\", \"rows\", updatedRows, \"input_tokens_removed\", removedTokens)\n\tif updatedRows == 0 || !cfg.rebuildRollup {\n\t\treturn nil\n\t}","sourceCodeStart":101,"sourceCodeEnd":137,"githubUrl":"https://github.com/multica-ai/multica/blob/2c0912b6ec764b373d44eeea1e80f0d9f11ab417/server/cmd/backfill_codex_usage_cache/main.go#L101-L137","documentation":"Returned when the dedicated connection's `SELECT pg_advisory_lock($1)` statement itself errors while taking the rollup advisory lock (rollupAdvisoryLockID). Note pg_advisory_lock blocks (waits) rather than erroring when the lock is held elsewhere, so this error signals a broken session — connection dropped, admin terminated the backend, or ctx cancelled mid-wait — not lock contention.","triggerScenarios":"The lock-holding connection dies while executing pg_advisory_lock (network reset, postgres restart, pg_terminate_backend); ctx cancelled while the statement is blocked waiting for another holder of the same lock ID (e.g. the scheduled rollup job holds it and SIGINT arrives).","commonSituations":"Postgres failover/restart during the backfill; a DBA killing the backfill backend; the hourly rollup job legitimately holding the lock and the operator Ctrl-C'ing the wait.","solutions":["Check postgres logs for restart/termination around the failure time; re-run once the server is stable.","If another long-running job holds the advisory lock, let it finish or coordinate, then re-run — the backfill is designed to be re-run safely.","Avoid sending signals while the tool reports waiting for the lock; let it block or stop the competing job instead."],"exampleFix":"# before\n./backfill_codex_usage_cache --cutoff ... --execute\n# acquire advisory lock 12345: context canceled (Ctrl-C while waiting)\n\n# after\n# let the lock holder finish, then re-run; the tool is idempotent per-batch\n./backfill_codex_usage_cache --cutoff 2026-01-01T00:00:00Z --execute","handlingStrategy":"retry","validationCode":null,"typeGuard":null,"tryCatchPattern":null,"preventionTips":["Don't interrupt the tool while it waits on the advisory lock; stop the competing lock holder instead.","Coordinate with the scheduled rollup job so both don't serialize on the lock during maintenance windows.","Check postgres logs for backend termination if this error appears without local signals."],"tags":["database","advisory-lock","backfill","postgres","concurrency"],"backgroundTag":null,"analyzedSha":"2c0912b6ec764b373d44eeea1e80f0d9f11ab417","analyzedAt":"2026-08-15T13:25:18.241Z","schemaVersion":2},"datasetVersion":"2026-08-15T17:31:12.345Z"}