Re: tx canceled on standby despite infinite max_standby_streaming_delay

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: tx canceled on standby despite infinite max_standby_streaming_delay
Дата
Msg-id CAKFQuwZh604YVP+sUPLRjjwtEMU_JeEQ07M8fLjYro12Bg35Qg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: tx canceled on standby despite infinite max_standby_streaming_delay  (Jay Howard <jhoward@alumni.utexas.net>)
Ответы Re: tx canceled on standby despite infinite max_standby_streaming_delay  (Jay Howard <jhoward@alumni.utexas.net>)
Список pgsql-general
Its customary to bottom-post (or respond inline) on these lists.

On Sun, May 15, 2016 at 7:01 PM, Jay Howard <jhoward@alumni.utexas.net> wrote:
Do you have hot_standby_feedback set to "on" ? 

It was off.  Will research that.  Thank you!

What is the parameter  max_standby_archive_delay configured to ? This will pause WAL archives from being applied when queries are executed on the standby database.

It's set to the default, which is 30 seconds.  For some reason I thought setting "max_standby_streaming_delay" to -1 would be sufficient.


​At minimum I think there is room for improvement in the documentation here since I spent probably a good 15-20 minutes trying to find an answer related to either vacuum or WAL accumulation and could not discover anything that directly permitted your situation to occur.​

At a high level, what's the difference between the "archive_delay" and "streaming_delay"?  I will read up on streaming replication in the mean time.

 
​"""
 When a conflicting query is short, it's typically desirable to allow it to complete by delaying WAL application for a little bit; but a long delay in WAL application is usually not desirable. So the cancel mechanism has parameters, max_standby_archive_delay and max_standby_streaming_delay, that define the maximum allowed delay in WAL application. Conflicting queries will be canceled once it has taken longer than the relevant delay setting to apply any newly-received WAL data. There are two parameters so that different delay values can be specified for the case of reading WAL data from an archive (i.e., initial recovery from a base backup or "catching up" a standby server that has fallen far behind) versus reading WAL data via streaming replication.
​"""

​David J.


В списке pgsql-general по дате отправления:

Предыдущее
От: "Peter J. Holzer"
Дата:
Сообщение: Re: Ascii Elephant for text based protocols
Следующее
От: Jay Howard
Дата:
Сообщение: Re: tx canceled on standby despite infinite max_standby_streaming_delay