Query cancellation on hot standby because of buffer pins

Поиск
Список
Период
Сортировка
От Drazen Kacar
Тема Query cancellation on hot standby because of buffer pins
Дата
Msg-id CAFxrd3tm_1_4UUL4ULnPzB04JJbvM1FdHpOMuF3fC7dW_8kJ2Q@mail.gmail.com
обсуждение исходный текст
Ответы Re: Query cancellation on hot standby because of buffer pins  (Kevin Grittner <kgrittn@ymail.com>)
Список pgsql-admin
Дерево обсуждения
I'm seeing query cancellation on hot standby (Postgres 9.3.4, configured with hot_standby_feedback=on) because of buffer pins being held for too long.

Database message looks like this:

ERROR:  canceling statement due to conflict with recovery
DETAIL:  User was holding shared buffer pin for too long.
STATEMENT: ...

I don't understand what kind of activity (either on primary or on standby) can cause this. The documentation about cancellation on standby lists access exclusive locks, vacuum and drops of tablespace or database on the primary as possible causes for cancellation on the standby.

I'm sure that neither of those things was happening on the primary when the query was cancelled on standby. I also don't know what "too long" means? That is, what's the timeout? I've looked at the source a bit and it seems that the timeout is the value of deadlock_timeout parametar, but I'm not very sure about that.

So can somebody explain why the query needs to be cancelled if it pins the buffer for too long and what exactly "too long" is?

The only thing I managed to find on the net is:
http://t61224.db-postgresql-bugs.dbtalk.info/bug-7546-backups-on-hot-standby-cancelled-despite-hot-standby-on-t61224.html

But that doesn't explain why this kind of cancellation happens.

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

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: PostgreSQL File System Based Backup Restartability
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: Query cancellation on hot standby because of buffer pins