Subject: Postgres template error — autovacuum_worker_slots in postgresql.conf line 687 crash-loops PG 17
gregredmond
PROOP

8 days ago

PostgreSQL Database directory appears to contain a database; Skipping initialization

2026-06-16 22:22:28.606 GMT [17] LOG: unrecognized configuration parameter "autovacuum_worker_slots" in file "/var/lib/postgresql/data/pgdata/postgresql.conf" line 687

2026-06-16 22:22:28.606 GMT [17] FATAL: configuration file "/var/lib/postgresql/data/pgdata/postgresql.conf" contains errors

Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/1c9d0823-5609-4b5c-8ebc-d768266f4e1e/vol_n7copvm1j3digwtg

$20 Bounty

2 Replies

Railway
BOT

8 days ago

This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.

Status changed to Open Railway 8 days ago


sumitdynamic99
HOBBY

7 days ago

This is usually caused by a PostgreSQL version mismatch. The mounted volume appears to contain a postgresql.conf generated by a newer PostgreSQL version, but the container is starting PostgreSQL 17, which doesn't recognize autovacuum_worker_slots. Check the deployed image version or remove that parameter from the config.


sumitdynamic99

This is usually caused by a PostgreSQL version mismatch. The mounted volume appears to contain a `postgresql.conf` generated by a newer PostgreSQL version, but the container is starting PostgreSQL 17, which doesn't recognize `autovacuum_worker_slots`. Check the deployed image version or remove that parameter from the config.

sumitdynamic99
HOBBY

7 days ago

The volume already contains an existing database and configuration, but the PostgreSQL version that's starting doesn't recognize autovacuum_worker_slots, so it fails during startup.

My guess is that the volume was created with a newer PostgreSQL version and is now being started with an older one. The database itself is probably fine. I would check which PostgreSQL version was previously running and compare it with the version being deployed now.

If that's the case, running the matching PostgreSQL version again or removing the autovacuum_worker_slots setting from postgresql.conf should resolve the issue


Welcome!

Sign in to your Railway account to join the conversation.

Loading...