У нас есть приложение с несколькими пакетами, часть этого пакета импортирует много данных, и мы работаем с drop / create.
Эти данные хранятся в postgresql 9.4, и удаление занимало слишком много времени, поэтому для правильной работы мы решили отменить ограничение внешнего ключа в начале пакета и заново создать его в конце.
НО мы имеем дело с тупиком ... во время пакетной обработки некоторые клиенты хотят публиковать данные, и эта публикация автоматически запускает обновление.
Затем во время создания или когда мы отбрасываем ограничения, возникает тупик.
На самом деле мы много чего пробовали и нашли интересные вещи.
Я прочитал почти 90% документации о режиме блокировки postgresql. И теперь я знаю, где у меня тупик (я думаю) и почти когда он появляется ..
Мы делаем таблицу изменений (пакетная обработка):
alter table A add CONSTRAINT fk_A_B FOREIGN KEY (id_B) REFERENCES B (id) NOT VALID;
или же :
àlter table A drop constraint fk_A_B
И пост клиента запускает это обновление:
UPDATE B SET colunmofb= ?, DATE_NOTIF = now() WHERE CAST(columndatetime AS DATE) = CAST(? AS DATE) AND x= ? AND 1 <= (SELECT count(B.id) FROM B INNER JOIN A a ON a.id_B = b.id ... other inner join and where clause
На самом деле я добавил not valid, чтобы быстрее создать ограничение fk, но когда приложение отправляет запрос на удаление / создание, мы можем иметь дело с тупиком, когда клиент сделал сообщение, и это было в момент UPDATE.
Я думаю, что это происходит в течение очень короткого времени ... когда мы drop/create constraint на таблицу A ссылаемся на B и когда UPDATE в качестве начала, но еще не выбрали данные в подзапросе? это правда или я совершенно не прав?
Но почему это появляется при ограничении сброса?
Я не могу найти ничего о режиме блокировки во время ограничения удаления на веб-сайте postgresql. Я думаю, что drop должен получить доступ к таблице ссылок, чтобы сделать какое-то действие до ограничения удаления, это правда? И если это правда, что я могу сделать, чтобы избежать тупиков?
Какие-нибудь рекомендации?
Спасибо;)
Редактировать 1: Я прочитал кое-что об ограничении триггера, задействованном fk_constraint, и было написано, что нам нужен исключительный блокировка для таблиц, потому что, с одной стороны, он сбрасывает триггер для таблицы А, которая отвечает за проверку при вставке, и за триггер в таблице. B, который отвечает за проверку удаления, чтобы сказать: «эту строку нельзя удалить, поскольку одна или несколько строк ссылаются на эту»
Я не знаю, правда ли это?
Редактировать 2: Я проверяю, и все, когда запускается таблица изменения с ограничением внешнего ключа (удаление или добавление ограничения), postgresql будет ожидать блокировки accessExclusive для обеих таблиц. Так что потенциальный тупик очень важен. Даже если это время действительно короткое, может появиться тупик.
Поэтому удаление ограничения с внешним ключом на postgres 9.4 совершенно не безопасно. Но я не могу объяснить, зачем Postgres нужна эта исключительная блокировка доступа в справочной таблице
PS: я прошу прощения за мой английский, я написал это очень быстро, потому что мне действительно нужен ответ: /