On Thu, 2026-10-29 at 10:45 +0100, Troels Arvin wrote: > I have a setup with a rather busy and semi-large primary Postgres server > which uses physical streaming replication to a secondary server. The > secondary server is to be used for read-only queries (reporting), and > I've starting running pg_dumps towards the secondary. > > I now run into error messages like the following when pg_dump works > against the secondary: > > pg_dump: error: Dumping the contents of table "sometable" failed: > PQgetResult() failed. > pg_dump: detail: Error message from server: ERROR: canceling statement > due to conflict with recovery > DETAIL: User query might have needed to see row versions that must be > removed. > pg_dump: detail: Command was: COPY someschema.sometable (col1, col2, > col3) TO stdout; > > I have tried setting > max_standby_streaming_delay = 5min > (Default is 30s.) That doesn't help. > > I'm wondering: Should I further raise max_standby_streaming_delay, for > example to 30min? > > Or should I set hot_standby_feedback to "on"?
If these are reporting queries, delaying replay is fine. So set "max_standby_streaming_delay" to -1, that will avoid query cancellation. Don't enable "hot_standby_feedback", otherwise reporting queries on the standby can bloat tables on your primary. Yours, Laurenz Albe
