LinYushen 24ea169d89 fix(migrate): serialize startup migrations with pg advisory lock (#3658) ...

cmd/migrate previously ran a check-then-apply loop on a *pgxpool.Pool
with no locking, so two backend pods starting at the same time (multi-
replica Deployment, scale-up, or a manual run overlapping with pod
startup) could both pass the EXISTS check on a pending migration and
race on the DDL or the schema_migrations INSERT, crashing the loser.

Take a single connection from the pool, hold a session-level
pg_advisory_lock for the entire migration loop, and release it on the
way out. We use the blocking variant so a late arriver queues behind
the current runner and then no-ops on the EXISTS checks instead of
crash-looping. The loop deliberately stays outside a transaction so
existing CREATE INDEX CONCURRENTLY migrations keep working.

Also refresh the values.yaml / backend.yaml comments next to
backend.replicas: the chart still ships replicas: 1 by default, but
that is now a recommendation (Recreate strategy, no leader split), not
a correctness requirement.

Refs https://github.com/multica-ai/multica/issues/3647

Co-authored-by: multica-agent <github@multica.ai>

2026-06-03 15:51:03 +08:00

..

templates

fix(migrate): serialize startup migrations with pg advisory lock (#3658)

2026-06-03 15:51:03 +08:00

Chart.yaml

feat(self-host): add Helm chart for Kubernetes deployment (#2377)

2026-05-25 12:53:01 +08:00

values.yaml

fix(migrate): serialize startup migrations with pg advisory lock (#3658)

2026-06-03 15:51:03 +08:00