ERROR: canceling statement due to conflict with recovery

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

ERROR: canceling statement due to conflict with recovery

RAJAMOHAN
Hello all,

Your expertise is needed on this. I was going through previous mails regarding the same topic and was able to setup the slave with hot_standby_feedback  enabled.
Queries are running fine with bloat occuring on master.

I tried the below scenario, where i disabled hot_standby_feedback and on table level disabled autovacuum for 2 big tables on master. Ran the query on the slave machine but still conflict error occurs.

I checked the pg_stat_database_conflicts view, the counter is increasing for confl_snapshot.  Cross-checked with pg_stat_user_tables view,  last time autovacuum happened for the 2 tables was 1 day before.


My doubt, even though no autovacuum and no DML activities happening for both the tables in master. Why is conflict error occuring?



Thanks & Regards,
Rajamohan.J

Reply | Threaded
Open this post in threaded view
|

Re: ERROR: canceling statement due to conflict with recovery

Toomas Kristin
Hi,

Basically I had the same topic recently and based on observation I would say that configuration parameter hot_standby_feedback disables no only some vacuuming operations but something else as well. I played thru the same scenario where I disabled hot_standby_feedback and and vacuuming, but still had conflicts on standby node. I am on opinion that the conflict is not related with the table that has disabled vacuuming the conflict may be related with any table instead that is used during the same session/connection.

I would suggest to make sure that application/client disconnects from standby node as soon as possible in order to release all possible locks/blockers on master that may cause bloating.

BR,
Toomas

On 24. Jun 2020, at 11:31, RAJAMOHAN <[hidden email]> wrote:

Hello all,

Your expertise is needed on this. I was going through previous mails regarding the same topic and was able to setup the slave with hot_standby_feedback  enabled.
Queries are running fine with bloat occuring on master.

I tried the below scenario, where i disabled hot_standby_feedback and on table level disabled autovacuum for 2 big tables on master. Ran the query on the slave machine but still conflict error occurs.

I checked the pg_stat_database_conflicts view, the counter is increasing for confl_snapshot.  Cross-checked with pg_stat_user_tables view,  last time autovacuum happened for the 2 tables was 1 day before.


My doubt, even though no autovacuum and no DML activities happening for both the tables in master. Why is conflict error occuring?



Thanks & Regards,
Rajamohan.J