> > Do you have hot_standby_feedback set to "on" ? > It was off. Will research that. Thank you!
What is the parameter max_standby_archive_delay configured to ? This will > pause WAL archives from being applied when queries are executed on the > standby database. > It's set to the default, which is 30 seconds. For some reason I thought setting "max_standby_streaming_delay" to -1 would be sufficient. At a high level, what's the difference between the "archive_delay" and "streaming_delay"? I will read up on streaming replication in the mean time. On Sat, May 14, 2016 at 8:20 PM, Venkata Balaji N <nag1...@gmail.com> wrote: > > On Sat, May 14, 2016 at 12:27 PM, Jay Howard <jhow...@alumni.utexas.net> > wrote: > >> I'm seeing long-running transactions (pg_dump) canceled on the standby >> when there are a lot of inserts happening on the master. This despite my >> having set max_standby_streaming_delay to -1 on the standby. >> > > Do you have hot_standby_feedback set to "on" ? > > What is the parameter max_standby_archive_delay configured to ? This will > pause WAL archives from being applied when queries are executed on the > standby database. > > >> Why might that happen? >> >> This is pg 9.3.12. When it happens I see: >> >> pg_dump: Dumping the contents of table "TABLE" failed: PQgetResult() >> failed. >> pg_dump: 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: The command was: COPY public.TABLE (COLUMNS) TO stdout; >> > > I suspect this is due to the clean up by VACUUM on primary. > > Regards, > Venkata B N > > Fujitsu Australia > > >
