Использование правил / триггеров PostgreSQL для отладки

Question

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

Приложение использует Spring для управления транзакциями, и я не смог найти никакой документации, относящейся к правилам транзакций. После нарушения все, что написано в транзакции, откатывается - это как-то повлияет на правило? Это Postgres 8.3.

Answer 1

После нарушения все, что написано в транзакции, откат - это как-то повлияет на правило?

Это также откатит все, что сделал правило. Вы можете создать триггер, который использует dblink , чтобы выполнить некоторую работу вне текущей транзакции. Другим вариантом может быть точка сохранения, но тогда вам придется изменить весь текущий код и транзакцию.

Уникальные нарушения также регистрируются в лог-файлах, получите эту информацию, чтобы увидеть, что происходит не так. Версия 9.0 содержит изменение, которое также сообщит вам, какие значения:

Улучшение сообщений об ошибках нарушения уникальности для сообщения значения, вызывающие сбой (Итагаки Такахиро) Например, Нарушение ограничения уникальности может теперь сообщать о Key (x) = (2) уже существует.

Answer 2

Вы можете делать практически все, что можете себе представить, с помощью правил и триггеров. А потом еще немного. Однако ваше точное намерение остается неясным.

Если транзакция все равно откатывается, как вы намекаете в конце, то все будет отменено, включая все побочные эффекты любых правил или триггеров. Твой план будет бесполезным.

Для этого есть обходной путь , если это действительно то, чего вы хотите достичь: используйте dblink , чтобы связать и ВСТАВИТЬ с таблицей в той же базе данных. Это не откат.

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

Answer 3

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

Правила можно использовать для принудительного применения ограничений, которые невозможно реализовать с помощью регулярных ограничений, таких как ключ, являющийся уникальным для нескольких таблиц, или другой многостоловый материал.(они имеют то преимущество, что «канареечное» имя таблицы отображается в журналах и сообщениях об ошибках) Но у OP уже было слишком много ограничений, кажется ...

Настройка уровня сериализации также, кажется, указаназадействовано несколько сеансов? использует ли фреймворк пул соединений?)