multica-ai/multica · error

acquire advisory lock %d: %w

Error message

acquire advisory lock %d: %w

What it means

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.

Source

Thrown at server/cmd/backfill_codex_usage_cache/main.go:119

		return err
	}
	logSummary(cfg, rows, total)
	if total.Rows == 0 {
		slog.Info("no eligible Codex task_usage rows found")
		return nil
	}
	if !cfg.execute {
		slog.Info("dry-run complete; review the summary, then re-run with --execute to apply the backfill")
		return nil
	}

	lockConn, err := pool.Acquire(ctx)
	if err != nil {
		return fmt.Errorf("acquire advisory-lock connection: %w", err)
	}
	defer lockConn.Release()
	if _, err := lockConn.Exec(ctx, `SELECT pg_advisory_lock($1)`, rollupAdvisoryLockID); err != nil {
		return fmt.Errorf("acquire advisory lock %d: %w", rollupAdvisoryLockID, err)
	}
	defer func() {
		_, _ = lockConn.Exec(context.Background(), `SELECT pg_advisory_unlock($1)`, rollupAdvisoryLockID)
	}()

	updateStartedAt, err := databaseClock(ctx, pool)
	if err != nil {
		return err
	}

	updatedRows, removedTokens, err := executeBackfill(ctx, pool, cfg)
	if err != nil {
		return err
	}
	slog.Info("task_usage rows updated", "rows", updatedRows, "input_tokens_removed", removedTokens)
	if updatedRows == 0 || !cfg.rebuildRollup {
		return nil
	}

View on GitHub (pinned to 2c0912b6ec)

Solutions

1. Check postgres logs for restart/termination around the failure time; re-run once the server is stable.
2. 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.
3. Avoid sending signals while the tool reports waiting for the lock; let it block or stop the competing job instead.

Example fix

# before
./backfill_codex_usage_cache --cutoff ... --execute
# acquire advisory lock 12345: context canceled (Ctrl-C while waiting)

# after
# let the lock holder finish, then re-run; the tool is idempotent per-batch
./backfill_codex_usage_cache --cutoff 2026-01-01T00:00:00Z --execute

When it happens

Trigger: 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).

Common situations: 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.

Related errors

• connect to database: %w
• ping database: %w
• acquire advisory-lock connection: %w
• rebuild hourly rollup for update window %s..%s: %w
• acquire advisory lock 4246: %w

AI-assisted analysis of multica-ai/multica@2c0912b6ec (2026-08-15). Data as JSON: /api/errors/84e19b6ac43329e3. Report an issue: GitHub.