At Thu, 18 Jun 2020 23:29:49 +0300, Toomas Kristin <toomas.kris...@gmail.com> 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
