5

PROBLEM!! After setting up my Logical Replication and everything is running smoothly, i wanted to just dig into the logs just to confirm there was no error there. But when i tail -f postgresql.log, i found the following error keeps reoccurring ERROR: could not start WAL streaming: ERROR: replication slot "sub" is active for PID 124898

SOLUTION!! This is the simple solution...i went into my postgresql.conf file and searched for wal_sender_timeout on the master and wal_receiver_timeout on the slave. The values i saw there 120s for both and i had to change both to 300s which is equivalent to 5mins. Then remember to reload both servers as you dont require a restart. Then wait for about 5 to 10 mins and the error is fixed.

Walters
  • 61
  • 1
  • 4
  • 1
    Any ideas what might have been hogging up resources and triggering the timeout? Seems like you fixed the symptom, but maybe not the root cause? – richyen Sep 03 '20 at 21:04
  • Upvoted as this fixed the issue I was having. For others, to reload config:SQL: SELECT pg_reload_conf(); As postgres user from command line: /usr/bin/pg_ctl reload – Giles Apr 23 '21 at 08:52

1 Answers1

0

We had an identical error message in our logs and tried this fix and unfortunately our case was much more diabolical. Putting the notes here just for the next poor soul but in our case, the publishing instance was an AWS managed RDS server and it managed (ha ha) to create such a WAL backlog that it was going into catchup state, processing the WAL and running out of memory (getting killed by the OS every time) before it caught up. The experience on the client side was exactly what you see here - timeouts and failed WAL streaming. The fix was kind of nasty - we had to drop the whole replication link and rebuild it (fortunately it was a test database so not harm done but it's a situation you want to avoid). It was obvious after looking on the publisher side and seeing the logs but from the subscription side more mysterious.

Darren
  • 548
  • 7
  • 10