Ограничения на изменения схемы PostgreSQL внутри транзакций? - PullRequest
Новая
       89

Ограничения на изменения схемы PostgreSQL внутри транзакций?

13 голосов
/ 10 июля 2009

Моя база данных связана с Oracle, поэтому я с удивлением обнаружил, что Postgres включает в себя изменения схемы в транзакциях - если вы начинаете одну, создаете таблицу и затем выполняете откат, таблица исчезает. Он также работает для добавления и удаления столбцов. Очевидно, это очень хорошо.

Мы собираемся внести некоторые изменения в способ развертывания дельт схемы, использующих эту функцию. Прежде чем мы это сделаем, я хотел бы узнать, насколько далеко распространяется транзакционная гарантия, но я не могу найти никакой информации об этом в документации. Я предполагаю, что я просто использую неправильные условия поиска - мои поиски просто идут в большие списки команд, которые включают слова «транзакция», «создать» и «таблица».

Может кто-нибудь дать мне несколько советов по документации или обсуждению изменений в транзакционной схеме в Postgres? (Мы используем 8.2.13, хотя мы будем обновляться в не слишком отдаленном будущем.) Или просто некоторые подробности об утверждении, которое не будет включено в транзакцию?

Ответы [ 5 ]

8 голосов
/ 10 июля 2009
  • nextval и setval над последовательностями никогда не отменяются.
  • REINDEX DATABASE
  • REINDEX SYSTEM

В вики PostgreSQL есть статья о транзакционном DDL

7 голосов
/ 10 июля 2009

Согласно быстрому grep для документов, эти команды не могут быть выполнены в транзакциях:

  • кластер
  • коммит подготовлен
  • создать базу данных
  • создать табличное пространство
  • отбрасывания
  • удалить базу данных
  • отбросить табличное пространство
  • подготовлен откат
  • 1020 * вакуум *
4 голосов
/ 01 сентября 2012

Начиная с версии 9.1 PosgreSQL, кажется, что операторы создания схемы действительно транзакционные. 

select * from pg_namespace where nspname = 'foo';
 nspname | nspowner | nspacl 
---------+----------+--------
(0 rows)

begin;
create schema foo;
rollback;

select * from pg_namespace where nspname = 'foo';
 nspname | nspowner | nspacl 
---------+----------+--------
(0 rows)

begin;
create schema foo;
commit;

select * from pg_namespace where nspname = 'foo';
 nspname | nspowner | nspacl 
---------+----------+--------
 foo     |       10 | NULL
(1 row)
2 голосов
/ 02 сентября 2013

Два сеанса, одновременно запускающих "CREATE TABLE", немного странны:

http://postgresql.1045698.n5.nabble.com/Errors-on-CREATE-TABLE-IF-NOT-EXISTS-td5659080.html

CREATE TABLE выполняет предварительную проверку, чтобы выяснить, не конфликтует ли имя существует. Если это так, он либо выдает ошибку (обычно), либо выходит с уведомлением (в случае ЕСЛИ НЕ СУЩЕСТВУЕТ). Но есть условие гонки: конфликтующая транзакция может создать таблицу после того, как мы сделаем эту проверку и прежде чем мы создадим это сами.

И инициатор связанных потоков, и я достигли этого в автоматизированных средах тестирования, так что это не намного больше, чем раздражение. (Я сомневаюсь, что это повлияет на вашу миграцию схемы, но это можно рассматривать как ограничение на изменения ddl) 

perl -MDBI -E 'fork; fork; $d=DBI->connect("dbi:Pg:dbname=$ENV{USER}");' \
 $d->do("CREATE TABLE a (b int)")'
DBD::Pg::db do failed: ERROR:
   duplicate key value violates unique constraint "pg_type_typname_nsp_index"
DETAIL:  Key (typname, typnamespace)=(a, 2200) already exists. at -e line 1.
0 голосов
/ 10 июля 2018

Из руководства раздел 13,5 (валютный контроль: предостережения):

Некоторые команды DDL, в настоящее время только TRUNCATE и перезапись таблицы формы ALTER TABLE не являются MVCC-безопасными. Это означает, что после усечение или перезапись коммитов, таблица будет пустой параллельные транзакции, если они используют снимок, сделанный до Команда DDL подтверждена. Это будет проблемой только для транзакции который не получил доступ к рассматриваемой таблице до команды DDL начал […]

Относительно переписывания таблицы в разделе ALTER TABLE упоминается

Добавление столбца с предложением DEFAULT или изменение типа существующий столбец потребует, чтобы вся таблица […] была переписаны. Как исключение при изменении типа существующего столбец, если предложение USING не изменяет содержимое столбца и старый тип является бинарно-принудительным для нового типа или неограниченный домен над новым типом, перезапись таблицы не требуется […] Добавление или удаление системного столбца oid также требует переписывания всего таблица.

...