Re: Conflict with recovery on PG version 11.6 - Mailing list pgsql-general

From Toomas Kristin
Subject Re: Conflict with recovery on PG version 11.6
Date
Msg-id F9F549BB-4EB9-4674-B7DF-B7A76229DE4C@gmail.com
Whole thread Raw
In response to Re: Conflict with recovery on PG version 11.6  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: Conflict with recovery on PG version 11.6  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-general
Hi,

> There can be other reasons:
>
> - replicated ACCESS EXCLUSIVE locks that conflict with queries
> - replicated ACCESS EXCLUSIVE locks that cause deadlocks
> - buffer pins that are needed for replication but held by a query
> - dropped tablespaces that hold temporary files on the standby

Thank you for ideas what to verify.

> I told you the remedies above, why don't you like them?

Basically I want to achieve situation where replication is not suspended  (lag is not more than 3 minutes) and
statementson standby are not terminated. Based on collected information I don’t see any connection between vacuuming on
masterand termination of statements on standby. I can temporarily disable vacuuming in order to be 100% sure this is
thecase. And when I set max_standby_streaming_delay either -1 or as a very big number then it helps avoid query
terminationbut doesn’t help me about suspended replication. All worked with same configuration on Postgres version
10.6,the issue started after version upgrade. 

This is the reason why I am very keen to find out real cause for the conflict.

BR,
Toomas




pgsql-general by date:

Previous
From: Ron
Date:
Subject: Re: Netapp SnapCenter
Next
From: Michael Paquier
Date:
Subject: Re: Parallel safety of contrib extensions