At Thu, 18 Jun 2020 23:29:49 +0300, Toomas Kristin <toomas.kristin@xxxxxxxxx> wrote in > 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 statements on standby are not terminated. Based on collected information I donʼt see any connection between vacuuming on master and termination of statements on standby. I can temporarily disable vacuuming in order to be 100% sure this is the case. And when I set max_standby_streaming_delay either -1 or as a very big number then it helps avoid query termination but 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. FWIW in case you haven't tried yet, if you could find a DETAILS: line following to the ERROR: canceling.." message in server log, it would narrow the possibility. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
