Re: Conflict with recovery on PG version 11.6

From: Toomas Kristin <toomas(dot)kristin(at)gmail(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Conflict with recovery on PG version 11.6
Date: 2020-06-18 20:29:49
Message-ID: F9F549BB-4EB9-4674-B7DF-B7A76229DE4C@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 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.

BR,
Toomas

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2020-06-18 23:00:33 Re: create batch script to import into postgres tables
Previous Message Pepe TD Vo 2020-06-18 19:54:44 Re: create batch script to import into postgres tables