Re: Conflict with recovery on PG version 11.6
От | Toomas Kristin |
---|---|
Тема | Re: Conflict with recovery on PG version 11.6 |
Дата | |
Msg-id | F9F549BB-4EB9-4674-B7DF-B7A76229DE4C@gmail.com обсуждение исходный текст |
Ответ на | Re: Conflict with recovery on PG version 11.6 (Laurenz Albe <laurenz.albe@cybertec.at>) |
Ответы |
Re: Conflict with recovery on PG version 11.6
|
Список | 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 по дате отправления: