За последние 24 часа нас посетили 24155 программистов и 1531 робот. Сейчас ищут 1272 программиста ...

Транзакции в PostgreSQL

Тема в разделе "PostgreSQL", создана пользователем AdmiralMontana, 27 ноя 2010.

  1. AdmiralMontana

    AdmiralMontana Активный пользователь

    С нами с:
    9 ноя 2010
    Сообщения:
    8
    Симпатии:
    0
    Здравствуйте!
    Выполняется ли хранимая процедура в PostgreSQL (язык pl/pgsql) в рамках одной транзакции.

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

    Вопрос: при неудачной операции в какой-либо из выше перечисленных цепочек (н/р вставка null в поле NOT NULL в какой-либо из таблиц) произойдет ли полный откат всех предыдущих измпенений?

    Или в теле исходной хп надо вручную открывать, а затем открывать транзакцию?

    И еще один вопрос по автоинкременту.
    В таблице есть поле ID INTEGER PRIMARY KEY NOT NULL DEFAULT nextval('my_sec');
    В х/п вставляю запись в эту таблицу и получаю ID вставленной записи с помощью функции currval('my_sec') для дальнейшего использования.

    Вопрос: если в момент между тем как я вставил новую запись и извлекаю currval('my_sec') другой пользователь вставляет новую запись в туже таблицу, не получу ли я значение my_seq (в первом случае) увеличенную не на 1, а на 2?

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

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    AdmiralMontana
    Не уверен, но по-моему, оба варианта одинаковы. Внешняя транзакция в любом случае откатит все изменения, иначе это косяк БД. Но и внутренняя транзакция каши не испортит, ибо транзакция является "ресурсоемкой" только в случае ROLLBACK, а в случае коммита вложенной транзакции ровным счетом ничего делать не нужно.

    Если скорость БД так критична - не уверен, что постгрес является наилучшим выбором. Я нередко читал, как его ругают именно за скорость.
     
  3. MiksIr

    MiksIr Активный пользователь

    С нами с:
    29 ноя 2006
    Сообщения:
    2.339
    Симпатии:
    44
    Функции работают внути одной "внешней" транзакции, т.е. ошибка в функции откатывает все сделанные изменения. Вложенные функции так же откатят все, включая изменения внешней функции. Но! В pl/pgsql есть возможность ловить исключения (BEGIN .. EXCEPTION ... END) - если применена такая конструкция, но на BEGIN реализуется SAVEPOINT, и ошибка откатит только изменения текущего блока. Так как блоки могут быть вложенные - получается типа вложенных транзакций. Подробнее в документации.

    Открыть транзакцию два раза у вас и не получится. В постгресе используются SAVEPOINT, а два раза сказать BEGIN низя.

    По автоинкременту. Счетчик глобальный, но его значение хранится привязанное к сессии (коннекту). Именно по-этому неполучится получить currval только установив сессию - будет ошибка, что счетчик не определен. На nextval изменяется глобальный счетчик атомарно и в сессию записывается текущее значение. Пока в этой сессии снова не будет применет nextval - он не изменится.

    PS: постгрес быстрый, особо на нормальном многоядровом железе.
     
  4. AdmiralMontana

    AdmiralMontana Активный пользователь

    С нами с:
    9 ноя 2010
    Сообщения:
    8
    Симпатии:
    0
    Cпасибо за ответы.
    Dagdamor если не posgresql, какую бд посоветуешь? в mysql плохо реализованы транзакции, а мне важна устойчивость бд.
     
  5. 440Hz

    440Hz Старожил
    Команда форума Модератор

    С нами с:
    21 дек 2012
    Сообщения:
    8.003
    Симпатии:
    1
    Адрес:
    Оттуда
    это где ж такое?
     
  6. igordata

    igordata Суперстар
    Команда форума Модератор

    С нами с:
    18 мар 2010
    Сообщения:
    32.408
    Симпатии:
    1.768
    AdmiralMontana
    мускул поддерживает несколько типов таблиц разного уровня защищенности
     
  7. igordata

    igordata Суперстар
    Команда форума Модератор

    С нами с:
    18 мар 2010
    Сообщения:
    32.408
    Симпатии:
    1.768
    AdmiralMontana
    всяк кулик свой шесток хвалит. у меня есть знакомый весьма крутой прогер, по моей оценке. Прогит только под mssql. Уважает ее.
     
  8. AdmiralMontana

    AdmiralMontana Активный пользователь

    С нами с:
    9 ноя 2010
    Сообщения:
    8
    Симпатии:
    0
    igordata, я читал про тип таблиц InnoDB(кажется так называется точно не помню) в MySQL, но пишут, что транзакции и там неважно реализованы, нет вложенных транзакций, и что MySQL вообще менее стабильна. Вообщем нужна такая субд, которая бы обеспечивала стабильность (ну и скорость) в многопользовательской и активно изменяющейся бд. MySQL подойдет? или PostgreSQL?
     
  9. MiksIr

    MiksIr Активный пользователь

    С нами с:
    29 ноя 2006
    Сообщения:
    2.339
    Симпатии:
    44
    Обе подойдут. Но если ваш DBA проектирует использование ХП, то постгрес - там ХП на голову выше.
     
  10. Zolingen

    Zolingen Активный пользователь

    С нами с:
    8 дек 2010
    Сообщения:
    2
    Симпатии:
    0
    Адрес:
    Москва
    ХП - тут постгря в не конкуренции. Скорость запросов в MySQL MyISAM таблицах выше на порядок при выборке данных, так что если у вас проект в основном SELECT'ы использует, то имеет смысл ставить MySQL. В остальных случаях постгря получше будет

    ----------
    Египет
     
  11. MiksIr

    MiksIr Активный пользователь

    С нами с:
    29 ноя 2006
    Сообщения:
    2.339
    Симпатии:
    44
    Тесты, пожалуйста, про "порядок"
     
  12. admyx

    admyx Активный пользователь

    С нами с:
    14 мар 2008
    Сообщения:
    2.159
    Симпатии:
    1
    Поддерживаю.
    Не замечал что-то охренительного быстродействия мускуля по сравнению С...

    При правильно построенной таблице и расставленных индексах, из таблицы с ~ 6 000 000 данных, выборка идет за какие-то несчастные миллисекунды.
    Пруф не приведу, ибо фпадлу. Но сам недавно столкнулся с этим =) Так что все перед глазами