kevinveenbirkenbachandClaude Opus 5.5 807cfbcefe fix(postgres): raise max_locks_per_transaction to 256 ...

GitLab's migration on its dedicated postgres sidecar failed with "ERROR: out of shared memory" and the hint to raise max_locks_per_transaction. The default of 64 locks per transaction cannot cover a schema that locks thousands of tables and indexes in one transaction: a reproduction on postgres:18 failed at table 7453 with the default and held 20000 tables at 256.

The value sits next to the other postgres tuning constants in group_vars/all/17_resource.yml and reaches both the central svc-db-postgres command and the per-app sidecar. The sidecar's new command keeps the image entrypoint and only adds the flag. The shared lock table grows to about 256 x max_connections entries, roughly 30 MB at the 400-connection cap.

Ported from 7690d2ca6d on feature/store-i18n, which kept the constant in the resource lookup that main no longer has.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

2026-10-01 22:19:10 +02:00

..

env

fix(env-templates): make dotenv_quote swarm-aware (compose strips, swarm preserves)

2026-06-14 19:08:45 +02:00

initdb.d

feat(sys-svc-rdbms): apply postgres extensions for shared:false consumers via initdb.d mount

2026-05-19 16:55:00 +02:00

services

fix(postgres): raise max_locks_per_transaction to 256

2026-10-01 22:19:10 +02:00

sql

fix(sys-svc-rdbms): keep the realignment out of the engine's first start

2026-08-30 13:43:06 +02:00

configuration.yml.j2

…