Жизнь продолжается. А мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL.

Главное событие

EDB Completes Acquisition of 2ndQuadrant

EDB поглотила 2ndQuadrant. Теперь всё будет под брендом EDB. Руководить будет CEO EDB Эд Бойджан (Ed Boyajian), а великий и ужасный Саймон Риггс (Simon Riggs) из 2ndQuadrant получит титул PostgreSQL Fellow и будет PG-евангелистом и техническим стратегом.

Не будем считать деньги, а напомним о вкладе в сообщество от обеих уважаемых, почтенных компаний (EDB основана в 2004-м, 2ndQuadrant — в 2001-м).
Если считать по участникам основных разработчиков PostgreSQL (core team), то счет 2:1 в пользу EDB: Bruce Momjian и Dave Page (PgAdmin) от EDB, против Peter Eisentraut от 2nd Quadrant. Брюс Момджан напомнил о неписанном правиле сообщества: в core team не должно быть больше половины разработчиков из одной компании. А в новом EDB — 3 из 5.

Если считать по главным контрибуторам (major contributors) в код PostgreSQL, то маятник качнулся в другую сторону: 5: 3 в пользу 2ndQuadrant — Andrew Dunstan, Álvaro Herrera, Petr Jelinek, Simon Riggs, Tomas Vondra против Devrim Gündüz, Robert Haas, Amit Langote.

Но у 2ndQuadrant есть ещё и один Заслуженный хакер (hackers emeritus) — Marc G. Fournier.

И ещё: Эд Байджан в своей статье на сайте 2ndQuadrant ссылается на COVID-19 как на силу, направляющую пользователей в сторону PostgreSQL, о чём говорится даже в некотором специальном исследовании.

Покупку уже успели обсудить на Postgres-вторниках Николая Самохвалова и Ильи Космодемьянского. Брюс Момджан оценил событие так: в целом положительно, но риски есть. Кроме изменений в core team ещё и минусы консолидации (меньше выбор, слабее конкуренция) и риск того, что процесс пойдёт и дальше: больше шанс, что какая-нибудь крупная компания может захотеть поглотить EDB.

Жизнь продолжается. А мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL.

На этот раз мы решили немного изменить формат Постгрессо: теперь никакого информационного равноправия. Об одних релизах и статьях будем рассказывать подробней, о других — в паре строк. Выбор субъективен, конструктивная критика приветствуется.

Релизы

PostgreSQL 13 beta 3

В 3-й бете есть изменения по сравнению с 2-й бетой, смотрите на страничке релиза.

Одновременно с Beta 3 вышли обновления: 12.4, 11.9, 10.14, 9.6.19 и 9.5.23. В них закрыты две обнаруженные бреши в безопасности, связанные с путём поиска (search_path) элементов (таблиц, функций, операторов и так далее) при создании расширений и при логической репликации. Два с лишним года назад была найдена уязвимость CVE-2018-1058, позволяющая использовать особенности работы с переменной search_path (она определяет порядок поиска в схемах при обращении к объектам БД) для запуска злокозненного кода. При неаккуратном использовании этой переменной, враг может перехватить управление над выполнением запросов и затем запустить произвольный SQL-код с правами атакуемого пользователя. Об этом можно прочитать, например, здесь. Эти опасности были объяснены, меры предосторожности перечислены. Теперь оказалось, что мер недостаточно при логической репликации и при создании расширений.

Жизнь продолжается. А мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL

Главное событие

PostgreSQL 13 Beta 2

Релиз беты состоялся. Загрузить можно отсюда, информация для бета-тестеров здесь.

Напоминаем, что в начале апреля мы сделали обзор нового в версии 13: Много ли нового в чёртовой дюжине (спойлер: много). С тех пор по определению радикальных изменений произойти не могло. Некоторые изменения по сравнению с beta 1 всё же есть, о них написано в анонсе. Release notes 13-й версии здесь. А на этой странице расписание грядущих релизов PostgreSQL.

Релизы

Жизнь продолжается. А мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL

Релизы

Есть ощущение, что поток релизов в промежутке длиной в месяц между этим и предыдущим выпуском Postgresso заметно истончился.

Жизнь продолжается. Продолжаем знакомить вас с самыми интересными новостями PostgreSQL

Главная новость

PostgreSQL 13beta

Вышла долгожданная Бета. Новшества и изменения подробно расписаны здесь, а информация для бета-тестировщиков тут. Кроме того есть и советы по установке на конкретные ОС: вот, например, пошаговая инструкция для RHEL/CentOS/Fedora.

В статье "Много ли нового в Чёртовой Дюжине?" мы уже подробно описали, чего нового ждать от версии (ответ: много). А если есть повод обсудить тему с англоязычными коллегами, то есть и английская версия.

Появляются и статьи, посвященные отдельным новым фичам. Габриэле Бартолини (Gabriele Bartolini, 2ndQuadrant) рассказывает, например о Backup manifests and pg_verifybackup in PostgreSQL 13. А о (auto)VACUUM вы найдёте 2 ссылке в нашем разделе статьи.

Релизы

PostgreSQL 12.3

Эта плановая версия решает в том числе проблему безопасности, найденную в инсталляторе для Windows. Вместе с ней вышли и 11.8, 10.13, 9.6.18, и 9.5.22. До этого можно было запустить зловредный код в директориях, куда был загружен инсталлятор, или в рабочей директории. Теперь четко прописаны пути исполняемых файлов. Проблема заведомо существовала и до 9.5, но это уже останется заботой обладателей этих старинных версий.

Database scaling is a continually coming future. DBMS get improved and better scaled on hardware platforms, while the hardware platforms themselves increase the performance, number of cores, and memory — Achilles is trying to catch up with the turtle, but has not caught up yet. The database scaling challenge manifests itself in all its magnitude.

Postgres Professional had to face the scaling problem not only theoretically, but also in practice: through their customers. Even more than once. It's one of these real-life cases that this article
will discuss.

Many thanks to Elena Indrupskaya for the translation. Russian version is here.

This article was written in Russian in 2019 after the PostgreSQL 12 feature freeze, and it is still up-to-date. Unfortunately other patches of the SQL/JSON will not get even into version 13.

Many thanks to Elena Indrupskaya for the translation.

JSONPath

All that relates to JSON(B) is relevant and of high demand in the world and in Russia, and it is one of the key development areas in Postgres Professional. The jsonb type, as well as functions and operators to manipulate JSON/JSONB, appeared as early as in PostgreSQL 9.4. They were developed by the team lead by Oleg Bartunov.

The SQL/2016 standard provides for JSON usage: the standard mentions JSONPath — a set of functionalities to address data inside JSON; JSONTABLE — capabilities for conversion of JSON to usual database tables; a large family of functions and operators. Although JSON has long been supported in Postgres, in 2017 Oleg Bartunov with his colleagues started their work to support the standard. Of all described in the standard, only one patch, but a critical one, got into version 12; it is JSONPath, which we will, therefore, describe here.

On April 8, PostgreSQL feature freeze took place, so only features committed earlier will get into version PostgreSQL 13. Probably, this version can hardly be considered revolutionary, since it has no conceptual changes. Some of critical patches were late to get into it, such as Table and Functions for the JSON/SQL standard, which had been desirable to be part of PostgreSQL 12, along with the JSONPath patch; plug-in warehouses did not appear either — only the interface is being finalized. The list of improvements is still impressive. We prepared a pretty complete overview of the patches included in the Baker's Dozen.

Жизнь продолжается. Продолжаем знакомить вас с самыми интересными новостями PostgreSQL

Главная новость

Feature Freeze
Функциональность 13-й версии PostgreSQL заморожена. Теперь только доработки и исправления багов. Список нового, вопреки многим ожиданиям, довольно обширный. Читайте нашу статью
Много ли нового в «Чёртовой дюжине», где много примеров. Но и в разделе Статьи Postgresso есть ссылки на статьи, посвященные отдельным фичам.

Релизы

Postgres Pro Enterprise 12.2.1

В этой версии совмещены новшества PostgreSQL 12 и особенности ветки Enterprise.
Расширение multimaster: как и в 11.x, и в других версиях Enterprise, рекомендуется использовать в конфигурации 2+1, когда один из узлов рефери. Подробнее в документации. А ещё теперь можно проверить согласованность данных на узлах кластера, используя функцию mtm.check_query().

В CFS теперь можно выбирать алгоритмы сжатия. Поддерживаются zstd (по умолчанию), zlib и pglz, но можно добавить другие алгоритмы.

Ещё одна ударная фича Enterprise — механизм PTRACK, необходимый для эффективной работы нашего приложения pg_probackup, — был основательно переработан и получил новый внешний API. Чтобы резервные копии, уже созданные с PTRACK в pg_probackup, работали в Postgres Pro Enterprise 12.x, нужно обновить pg_probackup до версии 2.2.6 или выше и настроить копирование PTRACK заново.

Важный патч дедупликации индексов B-tree (автор Анастасия Лубенникова, Postgres Professional) в PostgreSQL 13, но его функциональность уже есть в Enterprise 12.2.1. Причем исключение дубликатов можно отключить для создаваемых индексов, воспользовавшись параметром deduplicate_items команды CREATE INDEX. Об этом есть здесь.

Речь пойдёт всего лишь о PostgreSQL 13. 8 апреля состоялась «заморозка» — PostgreSQL feature freeze, теперь в эту версию войдут только те фичи, которые приняты до этой даты.

Революционной эту версию, пожалуй, трудно назвать. Кардинальных, концептуальных изменений в ней нет. К тому же не успели войти в неё такие важные патчи, как Table и Functions для стандарта JSON/SQL, которых хотелось видеть еще в PG12 рядом с патчем JSONPath; не появились готовые встраиваемые хранилища — лишь дорабатывается интерфейс. Но список доработок всё же впечатляет. Мы подготовили довольно полную сводку вошедших в Чёртову Дюжину патчей.

---

Изменения в командах SQL

CREATE DATABASE… LOCALE

Утилиты initdb, createdb и команда CREATE COLLATION имеют параметр LOCALE, позволяющий сразу указать значения для LC_CTYPE и LC_COLLATE. Теперь такая же возможность появилась в команде CREATE DATABASE:

CREATE DATABASE db_koi8r TEMPLATE template0 
    ENCODING 'KOI8R' LOCALE 'ru_RU.KOI8R';

Жизнь продолжается. Продолжаем знакомить вас с самыми интересными новостями PostgreSQL.

Релизы

Postgres Pro Enterprise 11.17.1 и Postgres Pro Standard 11.17.1

В Postgres Pro Enterprise 11.17.1 исправлены недостатки, на которые указали пользователи. Серьезные доработки сделаны в расширении multimaster:
— теперь рекомендуется использовать его в конфигурации с тремя узлами, один из которых голосующий. Подробнее здесь;
— устранена проблема раздувания WAL путём очистки точек синхронизации удалённого узла и исправления расчёта минимального требующегося LSN. Ранее раздувание WAL иногда случалось при удалении узла из кластера;
— устранена проблема с возвращением узла в кластер после длительного отключения этого узла;
исправлена ошибка в точке синхронизации при инициализации модуля multimaster, возникавшая в случае сбоя до первой синхронизации.
Кроме этого усовершенствован механизм встроенного пула соединений. По сравнению с предыдущей версией, в нём появились следующие новшества:
— параметр dedicated_users, позволяющий задать список пользователей, для которых в режиме пула соединений будут использоваться выделенные обслуживающие процессы;
— отдельные обслуживающие процессы теперь могут принимать подключения разных пользователей, так что все подключения к одной базе данных будут относиться к одному общему пулу.
Есть доработки, общие для Postgres Pro Enterprise 11.17.1 и Postgres Pro Standard 11.17.1. Например, утилита pg_probackup обновлена до версии 2.2.7, а mamonsu — до версии 2.4.4.
Об этих и других новшествах релиза есть в главке Замечания к выпуску из документации по PPE и PPS.

Postgres Pro Standard 12.2.1

Отличия этой версии от PostgreSQL 12 и от Postgres Pro Standard 11.17.1 можно проследить по соответствующим Замечаниям к выпуску.

После паузы (отпуск), продолжаем знакомить вас с самыми интересными новостями по PostgreSQL. Не будем придерживаться здесь строго отображения всех релизов и событий, произошедших после последнего, еще октябрьского выпуска Postgresso #17, но важнейшее, произошедшее ещё в конце 2019 всё же постараемся упомянуть.

Релизы

PostgreSQL 12.2
А также 11.7, 10.12, 9.6.17, 9.5.21, и 9.4.26 увидели свет 13 февраля. Последняя в списке и есть последняя: 27-й уже не будет. В 12.2 исправлено огромное количество (более 70) багов, обнаруженных в 12.1. Из них многие в секционировании.

Решили проблемы с правами в конструкции ALTER… DEPENDS ON EXTENSION. В 12.1 обладатели прав на DROP EXTENSION могли расправляться с объектами, зависимыми от этого расширения.

Улучшили производительность parallel hash join для процессоров с большим количеством ядер и для hash join с очень большими таблицами.

Postgres Pro Standard 12.1.1

Эта версия вышла в конце декабре 2019 и основана, соответственно, на PostgreSQL 12.1. Об особенностях этой версии можно прочитать в этой статье. Там подробно и с примерами рассматриваются:
— проверка версий ICU;
— оптимизация блокировок, джойнов и GROUP BY;
— поддержка PTRACK;
— WaitLSN;
и многое другое.

СУБД Postgres Pro Standard придумана для того, чтобы доставлять наши разработки пользователям быстрее, чем мы можем это сделать через PostgreSQL. Те фичи, которые еще не вошли в PostgreSQL, но находятся на твердом пути туда, мы включаем в Postgres Pro Standard. Также в Postgres Pro Standard входят некоторые расширения, которые востребованы нашими клиентами, но отсутствуют в обычной поставке PostgreSQL.

Иногда бывают исключения, когда в Postgres Pro Standard по просьбам юзеров и для их удовлетворения включаются и менее тривиальные фичи, которым по-хорошему место только в Postgres Pro Enterprise. В частности, это PTRACK, о нём ниже.

Не все, но изрядная доля дополнительных расширений и утилит, входящих в Standard, разработана в Postgres Professional. Все патчи Postgres Pro придуманы и реализованы нашими силами. Начнем с улучшений, потребовавших вмешательства в ядро СУБД.

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

Речь здесь будет не совсем о покрывающих индексах: строго говоря, в Postgres появились так называемые инклюзивные индексы. Но, по-порядку: покрывающий индекс — это индекс, который содержит все значения столбцов, необходимые запросу; при этом обращение к самой таблице уже не требуется. Почти. О «почти» и других нюансах можно прочитать в статье Егора Рогова, входящей в его индексный сериал из 10 (!) частей. А инклюзивный индекс создается специально для поиска по типичным запросам: к поисковому индексу добавляются значения полей, по которым искать нельзя, они нужны только для того, чтобы не обращаться лишний раз к таблице. Такие индексы формируются с ключевым словом INCLUDE.

Анастасия Лубенникова (Postgres Professional) доработала метод btree так, чтобы в индекс можно было включать дополнительные столбцы. Этот патч вошел в версию PostgreSQL 11. Но патчи для методов доступа GiST/SP-GiST не успели созреть до выхода этой версии. К 12-й GiST дозрел.

Приятно видеть знакомые фамилии в списке Acknowledgments официального релиза PostgreSQL 12. Мы решили свести вместе попавшие в релиз новшества и некоторые багфиксы, над которыми трудились наши разработчики.

1. Поддержка JSONPath

(В Release Notes это звучит как Add support for the SQL/JSON path language (Nikita Glukhov, Teodor Sigaev, Alexander Korotkov, Oleg Bartunov, Liudmila Mantrova)

Сам этот патч, возможности JSONPath и история вопроса обсуждались в деталях в отдельной статье здесь на хабре. JSONPath — серьезное достижение Postgres Professional и одно из главных новшеств PostgreSQL 12 вообще.

В 2014 году А.Коротковым, О.Бартуновым и Ф.Сигаевым было разработано расширение jsquery, вошедшее в результате в версию Postgres Pro Standard 9.5 (и в более поздние версии Standard и Enterprise). Оно дает дополнительные, очень широкие возможности для работы с json(b).

Когда появился стандарт SQL:2016, оказалось, что его семантика не так уж сильно отличается от нашей в расширении jsquery. Не исключено, что авторы стандарта даже поглядывали на jsquery, изобретая JSONPath. Нашей команде пришлось реализовывать немного по-другому то, что у нас уже было и, конечно, много нового тоже.

Хотя специальный патч с функциями до сих пор не закоммичен, в патче JSONPath уже есть ключевые функции для работы с JSON(B), например:

jsonb_path_query('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 2)') возвращает 3, 4, 5
jsonb_path_query('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 5)') возвращает 0 записей

Кроме того, были оптимизированы и некоторые функции, которые уже работали с JSON раньше. Этим успешно занимался Никита Глухов.

Например, оператор #>>, соответствующий функциям jsonb_each_text() и jsonb_array_elements_text(), раньше достаточно быстро преобразовывал JsonbValue в text, но работал неторопливо с другими типами. Сейчас всё работает быстро.

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Главные новости

Релиз-кандидат PostgreSQL 12

В релизе-кандидате вся функциональность идентична грядущему официальному релизу. Если вновь выявленные и недоисправленные баги будут закрыты в срок, то официальный релиз выйдет 3 октября. По сравнению с PG 12 beta 4 исправлено несколько багов, в основном связанных с ECPG — SQL, встраиваемом в C. Релиз-кандидат доступен.

• Подробно о релизе здесь;
• а здесь изменения в PG относительно PG 11;
• нерешенные проблемы (Open Issues) PG 12;
• сообщить о найденном баге.

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Главная новость июня

EnterpriseDB приобретена инвестиционным фондом Great Hill Partners. Сумма сделки не разглашается. Майкл Стоунбрейкер назначен техническим советником. Энди Палмер вошел в совет директоров EDB. Он известный ИТ-инвестор, сооснователь Vertica и автор главы в книге Making Databases Work: The Pragmatic Wisdom of Michael Stonebraker. Great Hill Partners — частный (непубличный) фонд, управляющий $2.7 млрд. Событие не менее впечатляющее, чем недавняя покупка Citus Microsoft-ом: из 5 участников Core Team двое сотрудники EDB.

Релизы

PostgreSQL 11.4, 10.9, 9.6.14, 9.5.18, 9.4.23 и 12 Beta 2

Этих релизов ждали не из-за новых фич, а из-за того, что надо было закрывать обнаруженную дырку в безопасности под кодовым названием CVE-2019-10164. Любой прошедший проверку при аутентификации по методу scram-sha-256 пользователь мог переполнить буфер в стеке, сменяя свой пароль на специально сконструированную строку. Этим способом можно было не только уронить сервер, но и выполнить произвольный код от имени пользователя ОС, запускающего PostgreSQL.

Подобная возможность переполнения существовала и в libpq, и эксплуатируя её, подставной сервер мог уронить клиентское приложение или выполнить коварный код на клиенте от имени пользователя, запускавшего это приложение.

Эта уязвимость проявилась только в относительно новых версиях PostgreSQL: 10 и выше, когда появилась SCRAM-аутентификация. На сайте сообщества можно увидеть «особую благодарность» Александру Лахину (Postgres Professional), который обнаружил проблему.

Можно почитать статью на эту тему: eVOL Monkey. Who's affected and how to protect your systems.

Postgres Pro Standard 11.4.1, 10.9.1, 9.6.14.1, 9.5.17.1 и Postgres Pro Enterprise 11.4.1

В этих версиях дыра в безопасности уже закрыта. Об этом и о других багфиксах можно прочитать в документации к соответствующей версии.

Эта статья — продолжение рассказа о новом в PostgreSQL 12. Мы уже разобрали SQL/JSON (патч JSONPath) в статье «Что заморозили на feature freeze 2019. Часть I. JSONPath», теперь очередь CTE.

CTE

CTE это Common Table Expression — общие табличные выражения, их еще называют конструкциями с WITH. Фактически это создание временных таблиц, но существующих только для одного запроса, а не для сессии. К ним можно обращаться внутри этого запроса. Такой запрос хорошо читается, он понятен, его легко видоизменять, если потребуется. Это очень востребованная вещь, и она в PostgreSQL давно.

Но удобства могут обойтись дорого. Проблемы связаны с материализацией выражения после AS внутри конструкции WITH… AS (). Его еще называют внутренним выражением и вычисляют перед тем, как начать вычисление остального, его нельзя встроить в запрос верхнего уровня (no inlining). Планирование этого выражения происходит без учета остальной части запроса. Такое поведение называют барьером для оптимизации, или fencing. Кроме того, сама материализация требует под себя work_mem. И если выборка большая, то начинаются проблемы (об этом, например, есть в докладе Ивана Фролкова на PGConf 2019).

Мы продолжаем публиковать видео и расшифровки лучших докладов с конференции PGConf.Russia 2019. Доклад Олега Бартунова на тему «Профессиональный Postgres» открывал пленарную часть конференции. В нем раскрыта история СУБД Postgres, российский вклад в разработку, особенности архитектуры.

Предыдущие материалы этой серии: «Типичные ошибки при работе с PostgreSQL» Ивана Фролкова, части 1 и 2.



Я буду рассказывать про профессиональный Postgres. Прошу не путать с компанией, которую я представляю сейчас — Postgres Professional.



Я действительно буду говорить о том, как Postgres, начинавшийся как любительская академическая разработка, стал профессиональным — таким, как мы его видим сейчас. Выскажу исключительно свое персональное мнение, оно не отражает мнение ни нашей компании, ни каких-либо групп.

После комитфеста 2019-03 произошла заморозка функциональности (feature freeze). У нас это почти традиционная рубрика: о прошлогодней заморозке мы уже писали. Теперь итоги 2019: что из нового войдет в PostgreSQL 12. В этой части обзора, посвященной JSONPath, используются в том числе примеры и фрагменты из доклада «Postgres 12 в этюдах», который прочитал Олег Бартунов на Saint Highload++ в СПБ 9 апреля сего года.