I'm running Postgres 9.3.4 with one hot standby. The standby has hot_standby_feedback = on configured:
SQL> select name, setting from pg_settings where name like '%standby%'; name | setting -----------------------------+--------- hot_standby | on hot_standby_feedback | on max_standby_archive_delay | 0 max_standby_streaming_delay | 0 synchronous_standby_names |
In the standby log I have this:
2015-01-12 07:23:07 UTC ERROR: canceling statement due to conflict with recovery 2015-01-12 07:23:07 UTC DETAIL: User was holding a relation lock for too long. 2015-01-12 07:23:07 UTC STATEMENT: ... JOIN table_t1 ...
2015-01-12 08:53:28 UTC ERROR: canceling statement due to conflict with recovery 2015-01-12 08:53:28 UTC DETAIL: User was holding a relation lock for too long. 2015-01-12 08:53:28 UTC STATEMENT: ... JOIN table_t1 ...
On the primary I have this:
2015-01-12 07:23:07 UTC LOG: automatic vacuum of table "xxx.xxx.table_t1": index scans: 0 pages: 0 removed, 273 remain tuples: 155 removed, 918 remain buffer usage: 131 hits, 78 misses, 16 dirtied avg read rate: 5.656 MB/s, avg write rate: 1.160 MB/s system usage: CPU 0.00s/0.00u sec elapsed 0.10 sec
2015-01-12 08:53:28 UTC LOG: automatic vacuum of table "xxx.xxx.table_t1": index scans: 1 pages: 0 removed, 273 remain tuples: 50 removed, 1057 remain buffer usage: 168 hits, 48 misses, 13 dirtied avg read rate: 6.046 MB/s, avg write rate: 1.637 MB/s system usage: CPU 0.00s/0.00u sec elapsed 0.06 sec
I was under impression that setting hot_standby_feedback to on would prevent query cancellation on the standby because of vacuuming on the primary.
Is there something else I should do in order to disable query cancelation on the standby?