Что такое ванильный postgresql
Олег Бартунов: Про «Postgres Pro»
Завтра рано утром я улетаю в Луклу навстречу треку, который я ждал целый год. Мы планируем пройти 5 высокогорных перевалов и 4 долины, увидеть еще раз высочайшие горы мира, ну и померзнуть в палатках, куда уж без этого. Моя голова уже почти отключилась от забот «того мира», но я попытаюсь объяснить зачем мы начали свои форки постгреса. Я уже наталкивался в сети на мифы вокруг наших сборок, что с одной стороны хорошо, ибо это означает, что дистрибутивами стали интересоваться и пользоваться, но это также означает, что мы недостаточно ясно пояснили наши мотивы. Поэтому я попробую это сделать сейчас, перед тем, как сдам ноутбук в камеру хранения.
Мне понравился этот монах, который стоически несколько часов стоял неподвижно, чем-то он был похож на отважного Щелкунчика. Я пожертвовал один раз, а потом не выдержал и положил денег еше раз.
Postgres Pro (он же Postgres Pro Standard), доступен с исходными текстами, включает некоторые наши патчи, которые уже попали в девелоперскую версию ванильного Постгреса, обычно отслеживает версии ванильного Постгреса, с которым сохраняет совместимость. Этим мы даем возможность пользователям быстрее попробовать новые фичи ванильного Постгреса.
Этот форк включает патчи для очистки памяти, проверки контрольных сумм бинарников и другие. Очевидно, что такие патчи сообществу совсем не нужны. Отмечу, что ванильный Постгрес недавно прошел сертификацию на Common Criteria, но на самый низший уровень, для которого не требовались дополнительные работы. Я надеюсь, что со временем ванильный Постгрес будет сертифицироваться на более высокие уровни и тогда мы сможем пропихнуть (отдадим) наши патчи безопасности и поддержка нашего форка станет легче.
(Примечание: это внутренняя условная нумерация, эти версии будут доступны пользователям под номерами, соответствующими актуальным релизам Postgres Pro)
История этого форка началась с совещания разработчиков Постгреса весной этого года (2016), на котором Саша Коротков представил план разработок Postgres Professional, который мы подготовили перед конференцией исходя из запросов наших клиентов. Наши планы вызвали большой интерес, другие компании тоже откликнулись своими планами, но мы не увидели желания сообщества что-то коренным образом менять. Много шумихи было вокруг версии 10.0, но ничего кардинального в ней не предполагается.
Где-то в июле 2016 года мы окончательно поняли (есть точная дата), что у сообщества другие интересы, а наши клиенты хотят новых фич уже сейчас, и нам надо самим начинать продвигать наши разработки в нашем собственном форке без оглядки на совместимость.
На этом разработки Postgres Pro Enterprise не заканчиваются, и мы обязательно напишем о них подробно. Мы также рассматриваем возможность включения поддержки 1С в энтерпрайз версию. Я надеюсь, что теперь понятна необходимость Postgres Pro Enterprise, которая в первую очередь предназначена для крупных клиентов.
На все эти продукты, а также на ванильный Постгрес, мы предоставляем техническую поддержку.
Мне кажется, что сейчас все должно быть кристально чистым.
Теперь про мифы. Чтобы написать про них, у меня не осталось времени и сил, так что просто дам ссылку на короткую презентацию «Russians in PostgreSQL» (видео), где я очень кратко показал 20-лет развития Постгреса и отметил российский вклад (красненьким цветом).
Пора мне паковаться, сдавать ноутбук в storage room, и немного поспать перед полетом в Луклу на маленьком самолетике, чтобы начать свой трек и окончательно раствориться в Гималаях. А вам всем желаю не ссориться, а просто принять тот факт, что мы создали нашу компанию Postgres Professional во благо всех, в том числе и ванильного Постгреса. Почитайте внимательно, если что-то непонятно, то проще прийти к нам в компанию и поговорить с нами, мы очень открыты, у нас проходят семинары, можно выступить, высказаться. На крайний случай, я доступен в ЖЖ, ФБ, ко мне обращаются сотни(!) людей, и я стараюсь со всеми быть откровенен и оказываю помощь. Этот месяц меня почти не будет в сети, я буду изредка что-то постить, чтобы показать прогресс нашего похода, но у меня не будет возможности оказывать профессиональную помощь, для этого вы можете воспользоваться контактами на нашем сайте.
База данных Postgres Pro: когда она лучше PostgreSQL
Есть в интернете такой сайт с индексом популярности СУБД — DB Engine. Открыв его, мы увидим в топе бесплатную опенсорсную базу PostgreSQL, которая сопоставима по возможностям и функциям с популярными коммерческими решениями. А есть еще и российская СУБД Postgres Pro, сделанная из исходников PostgreSQL.
Как и зачем в России сделали свою версию этой СУБД и кому она может понадобиться? Разбираемся в вопросе.
Postgres Pro и PostgreSQL: экскурс в мир популярного бэкенда
Еще лет 10-15 назад разработчики повально ставили на свои бэкенд-проекты популярную СУБД MySQL. У нее в те времена было огромное количество косяков — разваливались кластеры и реплики, тормозили индексы, тексты в таблицах превращались в кракозябры. Разработчики плакали, кололись, но продолжали есть кактус MySQL — несмотря на отвратительное качество работы, это было самое популярное, документированное и простое в установке решение на рынке.
PostgreSQL в то время уже существовала и по качеству работы рвала MySQL. Но меньшая популярность в сообществе программистов и необходимость вдумчиво читать документацию делала эту СУБД не столь популярной.
Как появилась российская СУБД Postgres Pro
Дикая популярность PostgreSQL привела к тому, что в России одна умная и успешная компания сделала свою версию этой СУБД — Postgres Pro. Ну а что? Код оригинальной БД открыт — при условии соблюдения определенных требований со стороны лицензии на свободное ПО можно делать свои продукты на основе публичного кода.
Комьюнити вокруг опенсорс-продуктов часто весьма инертное, некоторые правки и предложения вносятся в ядро кода годами — куда быстрее сделать свою копию кода и внести туда все, что считаешь нужным.
А еще у разных стран разные юридические требования к использованию программного обеспечения в системах. У России они тоже есть, и с ними нужно считаться. Так что вполне хватает причин создать свой, местный, вариант СУБД, использовав открытый код.
Так что предпосылки для создания таких проектов есть и они уже подтверждены рынком. Проекты российской компании Postgres Pro построены на этих же принципах.
Давайте разбираться, что нам предлагают.
Сравнение Postgres Pro и PostgreSQL: что добавилось в российской версии
Нам предлагают полнофункциональную версию PostgreSQL с кучей мощных доработок и сертификацией под Россию.
Postgres Pro является полным преемником традиционного PostgreSQL. А это значит, что мы держим в руках систему, ориентированную на максимальную функциональность и надежность хранимых данных. Она — идеальное решение для систем, где нельзя терять или случайно искажать данные. Основные сферы применения Postgres Pro: финансовый сектор, транспорт, складские поставки, системы управления бизнесом и так далее.
Надежность здесь не означает простоту и примитивность — Postgres Pro прекрасно справляется с добавлением специализированных процедур в свой встроенный язык запросов, хранением бинарных данных, географических точек, работой с JSON-документами. Все фичи крутой современной СУБД на месте! И они нисколько не замедляют работы этой системы — всё работает шустро и стабильно.
Postgres Pro (как и родительская PostgreSQL) хорошо масштабируется, и, как следствие, легко переносит выход из строя пары серверов БД, не теряя при этом данные и не переставая обслуживать клиентов.
Есть и кое-какие фичи, которых у родительской СУБД нет, например:
В целом — список доработок огромный, хватит на отдельную статью.
Тонкости эксплуатации, плюшки и особенности Postgres Pro Enterprise
7 лет пути
Расскажу для начала, какой путь мы прошли в 1С на PostgreSQL.
Версии Postgres для 1С
Но прежде чем окунуться в Enterprise, сначала напомню, какие версии PostgreSQL для 1С есть. В этом моменте у многих есть недопонимание.
PostgreSQL для 1С – самосборка
Версия №1 – это самосборка PostgreSQL для 1С на основе открытых исходников ванильной версии. Для тех, кто умеет собирать пакеты – это самая теплая ламповая сборка.
В чем ее особенности использования:
PostgreSQL для 1С – сборка фирмы «1С»
Есть сборка PostgreSQL от фирмы «1С». Она распространяется в двух видах – как дистрибутив и в качестве исходников набора патчей, которые нужно использовать для ванильного PostgreSQL.
В чем ее особенности:
PostgreSQL для 1С от Postgres PRO
Следующая сборка появилась недавно, в день проведения конференции Infostart Event 2019, от команды Postgres PRO. О ней объявил Олег Бартунов. Это сборка от команды Postgres PRO, скачать ее можно с сайта https://1c.postgres.ru. Это – ванильный Postgres, собранный с патчами для 1С и плюс некоторые улучшения, которые команда Postgres PRO считает важными для 1С и внедряет их.
Postgres PRO Standart
Еще одна такая же сборка с небольшой цензурой Postgres PRO Standart.
Получить ее можно, зарегистрировавшись на сайте Postgres PRO.
Postgres PRO Enterprise
Коммерческая сборка Postgres PRO Enterprise – чем она отличается от версии Postgres PRO Standart:
Фишки Enterprise, полезные для 1С
Теперь подробнее поговорим о фишках Enterprise, которые важны именно для 1С.
Все отличия Enterprise от не-Enterprise смотрите по ссылке https://postgrespro.ru/products/postgrespro/enterprise.
Теперь давайте подробнее рассмотрим, как это в жизни работает.
pg_hint_plan
pg_hint_plan – это не фишка Enterprise, это открытое расширение, которое вы можете спокойно внедрять в свои сборки, но в Enterprise оно уже внедрено.
Что оно делает? На просторах интернета можно встретить жалобы на то, что в 1С плохо работает отчет. Но если в настройках join_collapse_limit поставить 1 (вместо 8 или 20 – по умолчанию на разных сборках установлено по-разному), то отчет сразу начинает работать быстро, а вся остальная база «встает колом».
Для решения такого вида проблем есть pg_hint_plan. Вы можете влиять на план выполнения запроса, добавляя в комментариях нужные вам операторы, как показано на слайде.
Конкретно этот пример взят мной из документации. Здесь указано:
Ниже план выполнения, где видно, что Postgres выполняет команды так, как ему сказали.
Таким образом, независимо от того, как отработал планировщик – “Бог” СУБД, вы как программист можете выступить «помощником Бога» и исправить ошибки “Бога” так, как считаете нужным. Не факт, что это будет правильно или быстрее, но эксперты вполне могут себе позволить это делать.
Скорее всего, у вас не получится напрямую засунуть комментарий в код 1С так, чтобы платформа это правильно обработала и передала. Но в этом расширении есть крутая штука – таблица указаний, где вы можете шаблонно указать запрос и что с ним сделать.
Тут надо иметь в виду одну особенность – шаблон запроса это не маска, хоть и называется шаблоном. Чтобы эта настройка сработала, запрос должен прилетать всегда одинаковый.
А с помощью указания Set вы можете на время планирования запроса задать планировщику параметры GUC (например, указать join_collapse_limit=1 на ваш любимый отчет) – получается, что и запрос ускорится и база летать начнет.
Подробно запросы разбирать я не буду, но это незаслуженно забытое расширение, изучите его. Документации по нему много, очень крутая вещь, будущее у нее есть.
Поскольку не всегда мы можем дождаться исправления в платформе 1С, где, по нашему мнению, неправильная интерпретация запросов. А здесь вы можете сами взять и что-то подправить в планировщике.
Сжатие данных на уровне СУБД
Что дает сжатие данных на уровне СУБД:
Казалось бы, сжатие – крутая вещь, но когда мы ее начали использовать на 1С, нас начало не по-детски “штормить”.
На тот момент у нас были настройки сжатия, как на слайде. Не было только одной настройки – Compress first segment of relations.
Что это такое? По умолчанию сжатие происходит вообще всех элементов базы данных. Опять же напоминаю, что типовая Бухгалтерия содержит 5,5 тысяч таблиц и 27 тысяч индексов – итого 32 тысячи файлов.
Кроме того, Postgres каждый следующий гигабайт пишет в новый файл. Может быть, что одна наша база данных займет 300 тысяч файлов.
По умолчанию CFS попробует сжать все 300 тысяч файлов.
В результате мы получим у каждой базы вот такой файл-отражение со стандартным размером 1 мегабайт, поскольку именно в 1 мегабайте они могут удержать отражение 1 Гб данных.
Postgres не знает, что его сжали, он обращается к номеру страницы на диске, который у него в базе написан.
Система сжатия перехватывает этот запрос, и запрашивает в CFM-файле, где эти данные теперь в реальности находится – мы же сжали файлы, а оригиналы, грубо говоря, удалили, они находятся в другом месте. Это и называется файл-отражение, когда на каждый элемент создается файл размером 1 мегабайт.
В чем случилась беда? Наш первый тест на базе 1С показал следующее: CFS-worker бегает по всем файлам отражения и пытается их дефрагментировать – удалить оттуда то, что мы удалили из данных. Грубо говоря, еще один вакуум еще одного элемента. При таком количестве файлов, как в базе 1С, CFS-worker клали на лопатки любые дисковые системы. У нас система легла на 4 млн файлов – это 150 баз на сервере 1С.
После этих тестов разработчики PostgreSQL:
Дальнейшие исследования показали, что нельзя сжать табличное пространство по умолчанию. Изначально Postgres ставится и создает пространство-default. Но сжать уже созданное пространство нельзя, сжатие происходит путем создания пространства с сжатием.
Здесь можно пойти несколькими путями:
Как я уже сказал, каждый файл отражения весит 1 МБ, но это не реальное место, которое занимает файл на диске, а просто атрибут файла. В итоге можете получить интересный эффект. После сжатия 100-гиговой базы в свойствах Postgres вы обнаружите, что 100-гиговая фаза начала весить 250 гигов. Как же так, мы же сжали? Все просто: у вас образовалось 150 тысяч файлов отражений. Это пока не исправлено, нет отдельной процедуры, которая показывает правильный размер, либо я о ней не знаю.
Реальный размер в Linux проверяется через утилиту du (disk usage) – на слайде приведена командная строка, как проверять. Эта утилита покажет вам реальный размер, который данные занимают на диске, а не размеры, подсчитанные по атрибутам файлов. В pg_admin будет искаженная информация.
Еще одна особенность, обнаруженная случайно: оказывается, утилита pg_repak (по факту vacuum_full без блокировки данных), знает, но не учитывает tablespace у таблиц.
А поскольку при сжатии мы создаем отдельный tablespace, то pg_repack, когда вы натравите его на сжатую базу, перепакует таблицы в несжатое пространство, в default.
Что изменится в августе
Когда мы это все раскопали, нам показалось, что в целом можно запускаться. Но мы нарвались на две ошибки, которые нам обещают исправить в августе.
Я впервые встречаю вендора, с разработчиками которого можно общаться напрямую на русском языке, и они тебе отвечают в течение одной минуты, не ткнут носом в ошибку, пытаются разобраться и очень быстро и аккуратно исправляют баги.
Итак, когда мы подумали, что все окей, мы, как правильные эксплуататоры СУБД, решили настроить реплику и нарвались там на две ошибки. Эти ошибки нам обещают исправить в августе. Что это за ошибки?
С 1 сентября, когда с нас снимут все карантины, заодно мы получим полностью работающую Enterprise версию PostgreSQL со сжатием данных. Огромное спасибо разработчикам движка базы данных и моей команде 1С-ников, которые все это протестили.
P.S. Все исправления обнаруженных нами проблем со сжатием вошли в версию 12.5.1.
Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Новосибирск. Больше статей можно прочитать здесь.
Приглашаем всех принять участие в INFOSTART EVENT 2021 (6-8 мая, СПб).
Различия Postgres Pro Enterprise и PostgreSQL
1. Кластер multimaster
Расширение multimaster и его поддержка в ядре, которые есть только в версии Postgres Pro Enterprise, дают возможность строить кластеры серверов высокой доступности (High Availability). После каждой транзакции гарантируется глобальная целостность (целостность данных в масштабах кластера), т.е. на каждом его узле данные будут идентичны. При этом легко можно добиться, чтобы производительность по чтению масштабировалась линейно с ростом количества узлов.
В ванильном PostgreSQL есть возможность строить высокодоступные кластеры с помощью потоковой репликации, но для определения вышедших из строя узлов и восстановления узла после сбоя требуются сторонние утилиты, и хитроумные скрипты. multimaster справляется с этим сам, работает из коробки без использования внешних утилит или сервисов.
Масштабирование по чтению в ванильном PostgreSQL возможно при репликации в режиме горячего резерва ( Hot-standby ), но с существенной оговоркой: приложение должно уметь разделять read-only и read-write запросы. То есть для работы на ванильном кластере приложение, возможно, придется переписать: по возможности использовать отдельные соединения с базой для read-only транзакций, и распределять эти соединения по всем узлам. Для кластера с multimaster писать можно на любой узел, поэтому проблемы с разделением соединений с БД на пишущие и только читающие нет. В большинстве случаев переписывать приложение не надо.
С помощью логической репликации в ванильном PostgreSQL можно реализовать асинхронную двунаправленную репликацию (например BDR от 2ndQuadrant), но при этом не обеспечивается глобальная целостность и возникает необходимость разрешения конфликтов, а это можно сделать только на уровне приложения, исходя из его внутренней логики. То есть эти проблемы перекладываются на прикладных программистов. Наш multimaster сам обеспечивает изоляцию транзакций (сейчас реализованы уровни изоляции транзакций «повторяемое чтение» ( Repeatable Read ) и «чтение фиксированных данных» ( Read Committed ). В процессе фиксации транзакции все реплики будут согласованы, и пользовательское приложение будет видеть одно и то же состояние базы; ему не надо знать, на какой машине выполняется запрос. Чтобы этого добиться и получить предсказуемое время отклика в случае отказа узла, инициировавшего транзакцию, мы реализовали механизм 3-фазной фиксации транзакций (3-phase commit protocol ). Этот механизм сложнее, чем более известный 2-фазный, поэтому поясним его схемой. Для простоты изобразим два узла, имея в виду, что на самом деле аналогично узлу 2 обычно работает четное число узлов.
Рис. 1. Схема работы multimaster
Запрос на фиксацию транзакции приходит на узел 1 и записывается в WAL узла. Остальные узлы кластера (узел 2 на схеме) получают по протоколу логической репликации информацию об изменениях данных и, получив запрос подготовить фиксацию транзакции ( prepare transaction ) применяют изменения (без фиксации). После этого они сообщают узлу, инициировавшему транзакцию, о своей готовности зафиксировать транзакцию ( transaction prepared ). В случае, когда хотя хотя бы один узел не отвечает, транзакция откатывается. При положительном ответе всех узлов, узел 1 посылает на узлы сообщение, что транзакцию можно зафиксировать ( precommit transaction).
Здесь проявляется отличие от 2-фазной транзакции. Это действие на первый взгляд может показаться лишним, но на самом деле это важная фаза. В случае 2-фазной транзакции узлы зафиксировали бы транзакцию и сообщили об этом 1-му, инициировавшему транзакцию узлу. Если бы в этот момент оборвалась связь, то узел 1, не зная ничего об успехе/неуспехе транзакции на узле 2, вынужден был бы ждать ответа, пока не станет понятно, что он должен сделать для сохранения целостности: откатить или зафиксировать транзакцию (или фиксировать, рискуя целостностью). Итак, в 3-фазной схеме во время 2-ой фазы все узлы голосуют: фиксировать ли транзакцию. Если большинство узлов готово зафиксировать ее, то арбитр объявляет всем узлам, что транзакция зафиксирована. Узел 1 фиксирует транзакцию, отправляет commit по логической репликации и сообщает метку времени фиксации транзакции (она необходима всем узлам для соблюдения изоляции транзакций для читающих запросов. В будущем метка времени будет заменена на CSN — идентификатор фиксации транзакции, Commit Sequence Number ). Если узлы оказались в меньшинстве, то они не смогут ни записывать, ни читать. Нарушения целостности не произойдет даже в случае обрыва соединения.
2. 64-разрядные счетчики транзакций
Проблема переполнения счетчика носит название ( transaction ID wraparound ), поскольку пространство номеров транзакций закольцовано (это наглядно объясняется в статье Дмитрия Васильева). При переполнении счетчик обнуляется и идет на следующий круг.
Рисунок 2. Как действует заморозка транзакций, отставших больше, чем на полкруга.
Замена 32-разрядных счетчиков на 64-разрядные отодвигает переполнение практически в бесконечность. Необходимость в VACUUM FREEZE практически отпадает (в текущей версии заморозка все еще используется для обработки pg_clog и pg_multixact и в экстренном случае, о котором ниже). Но в лоб задача не решается. Если у таблицы мало полей, и особенно если эти поля целочисленные, ее объем может существенно увеличиться (ведь в каждой записи хранятся номера транзакции, породивших запись и той, что эту версию записи удалила, а каждый номер теперь состоит из 8 байтов вместо 4). Наши разработчики не просто добавили 32 разряда. В Postgres Pro Enterprise верхние 4 байта не входят в запись, они представляют собой «эпоху» — смещение (offset) на уровне страницы данных. Эпоха добавляется к обычному 32-разрядному номеру транзакции в записях таблицы. И таблицы не распухают.
Другая проблема 32-разрядных счетчиков в том, что обработка переполнений очень сложный процесс. Вплоть до версии 9.5 в соответствующем коде находили и исправляли весьма критичные баги, и нет гарантий, что баги не проявятся в следующих версиях. В нашей реализации 64-разрядного счетчика транзакций заложена простая и ясная логика, поэтому работать с нею и дальше ее развивать будет проще, чем бороться с переполнением.
Файлы данных систем с 64-разрядными счетчиками бинарно несовместимы с 32-разрядными, но у нас есть удобные утилиты для конвертации данных.
3. Постраничное сжатие
В нашей реализации страницы хранятся сжатыми на диске, но при чтении в буфер распаковываются, поэтому работа с ними в оперативной памяти происходит точно так же, как обычно. Разворачивание сжатых данных и их сжатие происходит быстро и практически не увеличивает загрузку процессора.
Поскольку объем измененных данных при сжатии страницы может увеличиться, мы не всегда можем вернуть ее на исходное место. Мы записываем сжатую страницу в конец файла. При последовательной записи сбрасываемых на диск страниц может значительно возрасти общая производительность системы. Это требует файла отображения логических адресов в физические, но этот файл невелик и издержки незаметны.
Для сжатия мы выбрали современный алгоритм zstd (его разработали в Facebook). Мы опробовали различные алгоритмы сжатия, и остановились на zstd : это лучший компромисс между качеством и скоростью сжатия, как видно из таблицы.
4. Автономные транзакции
Технически суть автономной транзакции в том, что эта транзакция, выполненная из основной, родительской транзакции, может фиксироваться или откатываться независимо от фиксирования/отката родительской. Автономная транзакция выполняется в собственном контексте. Если определить не автономную, а обычную транзакцию внутри другой (вложенная транзакция) то внутренняя всегда откатится, если откатится родительская. Такое поведение не всегда устраивает разработчиков приложений.
Автономные транзакции часто используются там, где нужны логирование действий или аудит. Например, необходима запись о попытке некоторого действия в журнал в ситуации, когда транзакция откатывается. Автономная транзакция позволяет сделать так, чтобы «чувствительные» действия сотрудников (просмотр или внесение изменений в счета клиентов) всегда оставляли следы, по которым можно будет в экстренной ситуации восстановить картину (пример на эту тему будет ниже).
В таких СУБД как Oracle и DB2 (но не MS SQL ) автономные транзакции формально задаются не как транзакции, а как автономные блоки внутри процедур, функций, триггеров и неименованных блоков. В SAP HANA тоже есть автономные транзакции, но их как раз можно определять и как транзакции, а не только блоки функций.
Во вложенных автономных транзакциях можно определять все доступные PostgreSQL уровни изоляции — Read Committed, Repeatable Read и Serializable — независимо от уровня родительской транзакции. Например:
BEGIN TRANSACTION
BEGIN AUTONOMOUS TRANSACTION ISOLATION LEVEL REPEATABLE READ
END ;
END ;
Все возможные комбинации работают и дают разработчику необходимую гибкость. Автономная транзакция никогда не видит результатов действий родительской, ведь та еще не зафиксирована. Обратное зависит от уровня изоляции основной. Но в отношениях их с транзакцией, стартовавшей независимо, будут действовать обычные правила изоляции.
В функциях синтаксис немного отличается: ключевое слово TRANSACTION выдаст ошибку. Автономный блок в функции определяется всего лишь вот так:
CREATE FUNCTION AS
BEGIN ;
BEGIN AUTONOMOUS
END ;
END ;
Соответственно уровень изоляции задать нельзя, он определяется уровнем родительской транзакции, а если он явно не задан, то уровнем по умолчанию.
Приведем пример, который считается одним из классических в мире коммерческих СУБД. В некотором банке в таблице customer_info хранятся данные клиентов, их долги
Пусть эта таблица будет недоступна напрямую сотруднику банка. Однако они имеют возможность проверить долги клиентов с помощью доступной им функции:
Перед тем, как подсмотреть данные клиента, функция записывает имя пользователя СУБД, номер эккаунта клиента и время операции в в таблицу лог:
Мы хотим, чтобы сотрудник имел возможность осведомиться о долгах клиента, но, дабы не поощрять праздное или злонамеренное любопытство, хотим всегда видеть в логе следы его деятельности.
Любопытный сотрудник выполнит команды:
BEGIN ;
SELECT get_debt (1);
ROLLBACK ;
В этом случае сведения о его деятельности откатятся вместе с откатом всей транзакции. Поскольку нас это не устраивает, мы модифицируем функцию логирования:
Теперь, как бы не старался сотрудник замести следы, все его просмотры данных клиентов будут протоколироваться.
Автономные транзакции удобнейшее средство отладки. Сомнительный участок кода успеет записать отладочное сообщение перед тем, как неудачная транзакция откатится:
BEGIN AUTONOMOUS
INSERT INTO test (msg) VALUES ( ‘STILL in DO cycle. after pg_background call: ‘ ||clock_timestamp():: text );
END ;
PERFORM * FROM pg_background_result(pg_background_launch (query))
AS (result text );
PS. Продолжение следует!
PPS. Мы будем рады узнать ваше мнение об актуальности и возможных применениях этих новшеств!