Добрый вечер.

Вот такая ошибка возникает при потоковой репликации и длинном запросе.


ОШИБКА: выполнение оператора отменено из-за конфликта с процессом восстановления
DETAIL: Пользователь удерживал блокировку таблицы слишком долго.


Подскажите пожалуйста из-за чего эта ошибка?


И как от нее избавиться?

Melkijuser_t0,

из-за конфликта репликации, как написано. Репликация говорит делай Х, реплика видит "не могу сделать Х, оно ещё нужно моему выполняемому запросу".. Что делать реплике?

- ждать завершение запроса и приостановить репликацию
- продолжить репликацию и отменить запущенный запрос

Сначала ждём до max_standby_streaming_delay, затем отменяем.

Спасибо за ответ.



Но, на мастере есть слот репликации, который связан с репликой.


Я думал он как раз и служит для того, чтобы не было подобных конфликтов и чтобы он держал нужные реплике данные на мастере, не позволяя их вычищать вакууму.

Т.е. получается что в любом случае запрос не может быть дольше чем max_standby_streaming_delay ? (Хоть со слотом хоть без)

Как же тогда настроить мастер-реплика, чтобы реплика могла выдержать запросы по несколько минут и при этом не было отставания от мастера более чем 10-20 сек ?

Melkijuser_t0Но, на мастере есть слот репликации, который связан с репликой.

Я думал он как раз и служит для того, чтобы не было подобных конфликтов и чтобы он держал нужные реплике данные на мастере, не позволяя их вычищать вакууму.
Вообще никак не связан.
Слот репликации - чтобы база не удалила WAL. Писать в WAL база может что угодно и сколько угодно пока не закончится место на диске.
Реплика может вовсе не использовать протокол репликации и быть всё равно репликой. Старые file shipping через archive_command/restore_command - в этом случае между мастером и репликой канала связи может не быть в принципе.

user_t0Т.е. получается что в любом случае запрос не может быть дольше чем max_standby_streaming_delay ? (Хоть со слотом хоть без)
Может, max_standby_streaming_delay считается от начала конфликта репликации.

user_t0Как же тогда настроить мастер-реплика, чтобы реплика могла выдержать запросы по несколько минут и при этом не было отставания от мастера более чем 10-20 сек ?
hot_standby_feedback если вы понимаете как это будет воздействовать на весь кластер.

Благодарю, картина проясняется.

Правильно ли я понял что слот репликации нужен только для того, чтобы мастер не удалил WAL файлы, которые не применились на реплике? Т.е. на потоковую репликацию он вообще не влияет пока она не станет файловой (из-за недоступности порта, например).

hot_standby_feedback - это реплика сообщает какой минимальный номер транзакции ей требуется и мастер его держит.
Соответсвенно, длинные транзакции на реплике начинают так же влиять на мастер, как если бы они на нем выполнялись.

Или есть еще какие-то подводные камни с hot_standby_feedback?