Порядок блокировок в запросе (PostgreSQL)

база данных имеет таблицу X и таблиц An, Bn, Cn, Dn, который наследует от X.Порядок блокировок в запросе (PostgreSQL)

Процесс запросы периодически данные из X.

Процесс обновляет данные в дочерних таблицах. Например, для обновления таблиц An и Bn он создает новые таблицы Am и Bm, загружает в них данные, блокирует доступ эксклюзивным An, Bn, падает An и Bn и изменяет Am и Bm для наследования X.

Проблема заключается в том, что когда процесс 1 выполняет запрос (например, select * from X), он блокирует таблицы An, Bn, Cn, Dn в общем режиме и порядок блокировки неизвестен. Если процесс 1 блокирует Bn, то процесс 2 блокирует. Мы зашли в тупик.

Есть ли информация о порядке блокировки таблиц в запросах в postgresql (без явной блокировки)? Или возможны другие решения?

источник

2010-06-27 valodzka

SELECT не блокирует таблицу, если вы не указали явно для блокировки. Вы проверяли pg_locks, чтобы узнать, что происходит? http://www.postgresql.org/docs/8.4/interactive/view-pg-locks.html –

Таблица блокировок SELECT (http://www.postgresql.org/docs/8.1/static/explicit-locking.html) , и в моем случае он ограничивается эксклюзивным запросом на отказ. ДОСТУПНАЯ АКЦИЯ Конфликты только с режимом блокировки ACCESS EXCLUSIVE. Команды SELECT и ANALYZE получают блокировку этого режима в ссылочных таблицах. В общем случае любой запрос, который только считывает таблицу и не изменяет ее, получит этот режим блокировки. – valodzka

Это конфликтует из-за ACCESS EXCLUSIVE, это ваша проблема. Сам SELECT не является проблемой. –

Я знаю, что вы сказали без явного блокирования, но, честно говоря, ваш лучший выбор здесь is явная блокировка. Поскольку первый оператор в обеих партиях имеет команду lock, которая блокирует таблицы, которые вы будете использовать. Самая важная часть этого вопроса состоит в том, что команды lockдолжны заблокировать таблицы в том же порядке, иначе вы все равно столкнетесь с тупиками.

После этого убедитесь, что обе партии работают как можно быстрее, так как вы берете блокировки на уровне стола ... вы не хотите удерживать их дольше, чем вы должны.

источник

2010-06-27 20:56:39 Donnie

Я немного упростил: процесс 1 не является пакетным заданием, это очень много процессов, которые выполняют множество разных запросов. Будет очень неприятно использовать явную блокировку для каждого запроса. Если заказ postgresql был предсказуемым, было бы намного проще изменить порядок блокировки процесса 2. – valodzka

Вот почему вы не должны упрощать свои вопросы.Тем не менее, параметры остаются неизменными: либо делать явные блокировки, либо обрабатывать блокировки при сбое (поскольку postgres обнаруживает взаимоблокировки и убивает один из задействованных procsses, чтобы другой мог завершить это, является опцией). – Donnie

Есть ли информация о порядке запирающих таблиц в запросах в PostgreSQL (без явной блокировки)? Или могут быть другие решения: возможно?

Обычно реализация postgresql 'mvcc защитит вас от многих типов взаимоблокировок. См. http://www.postgresql.org/files/developer/transactions.pdf для более подробной информации.

Хотя общее решение заключается в том, чтобы просто обрабатывать взаимоблокировки, то есть, если ваш запрос завершился неудачно из-за взаимоблокировки, повторите попытку.?

источник

2010-06-27 21:07:37 nos

Порядок блокировок в запросе (PostgreSQL)

ответ

Смежные вопросы