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