PostgreSQL logical replication (WAL streaming) connections drop with "unexpected EOF" every few minutes
mirantes
PROOP

22 days ago

I'm running a CDC (Change Data Capture) service that uses PostgreSQL logical replication to sync data between microservices in real-time.

Problem:

The START_REPLICATION streaming protocol connections are unstable. They either fail to establish (hang indefinitely) or drop every 2-10 minutes with "unexpected EOF on standby connection".

This happens on both internal networking (*.railway.internal:5432) and the external proxy (*.proxy.rlwy.net).

Regular SQL queries to the same databases work perfectly - only the streaming replication protocol is affected.

Error messages from PostgreSQL logs:
could not receive data from client: Connection reset by peer

unexpected EOF on standby connection

These appear after the connection has been streaming for a few minutes. PostgreSQL successfully accepts the connection and starts logical decoding, but the connection drops shortly after.

Error from my application:
Failed to subscribe to slot 'lightstream_user_db_slot': Subscription timeout after 90 seconds.

$40 Bounty

4 Replies

mirantes
PROOP

22 days ago

The subscribe sometimes takes multiple retry attempts before succeeding.

Setup:

  • Multiple PostgreSQL databases on Railway (all with wal_level = logical)

  • Bun/TypeScript service using pg-logical-replication npm package

  • Replication slots and publications are set up correctly

  • Service runs on Railway connecting via internal networking


mirantes
PROOP

22 days ago

What works:

  • Regular SQL queries (SELECT, INSERT, UPDATE) - no issues

  • Creating replication slots via SQL - works fine

  • Logical decoding starts successfully on PostgreSQL side


mirantes
PROOP

22 days ago

Questions:

  1. Does Railway's networking support PostgreSQL's streaming replication protocol for long-lived connections?

  1. Are there TCP keepalive or idle timeout settings that could be terminating these connections?

  1. Is there a recommended approach for services needing persistent streaming connections to PostgreSQL on Railway?

Any help would be appreciated. Happy to share more logs or details.


have you tried setting tcp_keepalives_idle, tcp_keepalives_interval, and

tcp_keepalives_count on your PostgreSQL connection? Something like:

tcp_keepalives_idle = 30

  tcp_keepalives_interval = 10

  tcp_keepalives_count = 3
Also Railway's proxy/networking has a TCP idle timeout that kills connections that appear inactive


Loading...