17 days ago
I need wal_level=logical enabled on two PostgreSQL services to set up
logical replication to a Supabase DR replica.
Service 1 — Production
Project ID: [5a50dfa7-09f3-4ebf-9c20-e7a6435f216d]
Service: 3d532575-3cd7-4582-9f51-4756bb18414a
Service 2 — Staging
Project ID: [5a50dfa7-09f3-4ebf-9c20-e7a6435f216d]
Service: [dabe7a8c-20e8-48d6-8e92-578ae71d6f58
ALTER SYSTEM SET wal_level='logical' succeeds on both but reverts to
'replica' after restart — the container appears to override
postgresql.auto.conf externally.
Please set wal_level=logical on both services and trigger a restart.
max_replication_slots=10 and max_wal_senders=10 are already set.
1 Replies
17 days ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 17 days ago
17 days ago
Railway’s current Postgres docs say this template is effectively unmanaged and that Postgres config changes should be applied via ALTER SYSTEM, then a deployment restart.
So in the normal case, this should be enough:
ALTER SYSTEM SET wal_level = 'logical';
ALTER SYSTEM SET max_replication_slots = 10;
ALTER SYSTEM SET max_wal_senders = 10;
SELECT pg_reload_conf();
SHOW wal_level;Then restart the PostgreSQL deployment from the 3-dot menu and check again with:
SHOW wal_level;
SELECT name, setting, source
FROM pg_settings
WHERE name IN ('wal_level', 'max_replication_slots', 'max_wal_senders');If it still comes back as replica after a real deployment restart, that suggests the service startup/image is overriding the config on boot rather than this being something Railway support needs to flip manually.
In that case, Railway’s own Postgres docs point to the next step: fork/customize their postgres-ssl image/repo and run your own Postgres service with the exact replication settings you need.