postgres 13 что нового
PostgreSQL 13 Press Kit 
Contents
Original Press Release
PostgreSQL 13 Released!
PostgreSQL 13 содержит существенные улучшения систем индексирования и поиска данных, которые будут полезны при работе с большими БД. Среди таких улучшений: экономия места и прирост производительности индексов; меньшее время ответа для запросов, которые используют агрегацию и секционирование; лучшее планирование запросов при использовании расширенной статистики.
Наряду с такими давно ожидаемыми возможностями как параллелизация очистки (vacuuming) и инкрементальная сортировка, PostgreSQL 13 обеспечивает намного более удобную работу по управлению данных, в больших и малых масштабах, превнося оптимизации процессов ежедневного администрирования, удобства для разработчиков приложений и улучшения безопасности.
PostgreSQL, инновационная система управления данными, известная своей надёжностью и производительностью, пользуется плодами 25 лет открытой разработки, осуществляемой глобальным сообществом разработчиков). В результате сегодня во всём мире организации любого размера отдают предпочтение PostgreSQL как СУБД с открытым иходным кодом.
Прирост производительности, снова и секционирования
Опираясь на работу в предыдущем релизе PostgreSQL, PostgreSQL 13 теперь может эффективно работать с дублирующимися данными в индексах B-tree, основном виде индексов в база данных (БД). Это снижает количество места, занимаемого индексами B-tree, при этом одновременно улучшая общую производительность запросов.
В PostgreSQL 13 ещё больше типов запросов с агрегацией и наборов для группировки (grouping sets) могут получать выгоду от применения эффективного хэш-агрегирования PostgreSQL, так как запросы с большими объёмами данных при агрегировании не обязательно должны помещаться в памяти. Запросы с секционированными таблицами получили улучшение производительности, так как теперь существует больше вариантов, когда секции могут быть отсечены и когда секции могут быть соединены напрямую.
Оптимизации задач администрирования
Очистка (vacuuming) ― это существенная часть PostgreSQL-администрирования, позволяющая БД переиспользовать место после удаления и обновления строк. Данный процесс может приводить к различным трудностям при администрировании, хотя в предыдущих релизах PostgreSQL и была проделана заметная работа по уменьшению накладных расходов процессов очистки.
PostgreSQL 13 улучшает систему очистки за счёт параллелизации очистки индексов. Это ускоряет процесс очистки. Кроме того, администраторы могут использувать новую возможность для тюнинга под конкретные нагрузки, выбирая, какое количество параллельных процессов очистки запускать. Помимо этого улучшения, вставка данных может теперь вызывать запуск процесса автоочистки.
Слоты репликации, которые используются для предотвращения удаления файлов журнала предзаписи (WAL) до того, как они получены репликой, в PostgreSQL 13 могут быть настроены с указанием максимального количества WAL-файлов, которые разрешается сохранить. Это позволяет защититься от ситуаций, когда место на диске закончилось.
Удобства разработки приложений
Система секционирования PostgreSQL стала более гибкой, так как секционированные таблицы стали полностью поддерживать логическую репликацию и BEFORE-триггеры уровня строки.
Улучшения безопасности
Для работы с приложениями, которым требуются безопасные методы аутентификации, PostgreSQL 13 разрешает требовать от клиентов «привязку канала» (channel binding) при использовании SCRAM-аутентификации, а обёртка сторонних данных PostgreSQL ( postgres_fdw ) теперь может использовать аутентификацию на основе сертификатов.
О PostgreSQL
PostgreSQL является ведущей СУБД с открытыми исходными текстами, с глобальным сообществом из тысяч пользователей и разработчиков, объединяющим множество компаний и организаций. Проект PostgreSQL базируется на более чем 30-летнем опыте проектирования и разработки, начавшихся в Калифорнийском университете Беркли, и в настоящее время продолжает развиваться беспрецедентными темпами. Богатый набор возможностей PostgreSQL не только не уступает ведущим коммерческим СУБД, но и превосходит их развитой функциональностью, расширяемостью, безопасностью и стабильностью.
Ссылки
Copyright © 1996-2021 The PostgreSQL Global Development Group
Много ли нового в Чёртовой Дюжине?
Речь пойдёт всего лишь о PostgreSQL 13. 8 апреля состоялась «заморозка» — PostgreSQL feature freeze, теперь в эту версию войдут только те фичи, которые приняты до этой даты.
Революционной эту версию, пожалуй, трудно назвать. Кардинальных, концептуальных изменений в ней нет. К тому же не успели войти в неё такие важные патчи, как Table и Functions для стандарта JSON/SQL, которых хотелось видеть еще в PG12 рядом с патчем JSONPath; не появились готовые встраиваемые хранилища — лишь дорабатывается интерфейс. Но список доработок всё же впечатляет. Мы подготовили довольно полную сводку вошедших в Чёртову Дюжину патчей.
Изменения в командах SQL
Предположим, что столбцу забыли задать имя:
Это можно исправить:
Генерируемый столбец таблицы теперь можно сделать обычным, то есть удалить выражение для его вычисления:
Впоследствии решили, что следует явно задавать income_tax. Удаляем выражение:
Разумеется существующие данные из столбца никуда не делись:
Подключимся к новой базе данных:
Если для новых таблиц требуется использовать другую стратегию, то можно изменить базовый тип:
Изменится и тип хранения в новых таблицах:
Нужно иметь в виду, что изменить стратегию, предполагающую использование TOAST, обратно на plain нельзя:
Поэтому эксперименты проводились в отдельной БД, которую не жалко удалить.
FETCH FIRST с опцией WITH TIES
Как известно, в команде SELECT вместо указания LIMIT можно пользоваться синтаксисом, определенным в стандарте SQL:
Встроенные функции и типы данных
get_random_uuid
Новая функция get_random_uuid возвращает значение UUID версии 4(случайное значение):
Функция полезна для генерации уникальных значений типа UUID в распределенных системах.
Раньше надо было пользоваться библиотеками uuid-ossp или pgcrypto.
Функция min_scale определяет количество значащих цифр в дробной части числа, а функция trim_scale отбрасывает незначащие нули:
Пополнение в разделе математических функций. Теперь можно быстро найти наибольший общий делитель( gcm ) и наименьшее общее кратное( lcm ):
В предыдущих версиях у возвращаемого значения функции не проверялся модификатор типа.
Предположим, есть тип для хранения денежных единиц и функция, возвращающая размер подоходного налога:
Вызывая функцию, мы ожидаем получить два знака после запятой, однако получаем четыре. Не помогает даже явное приведение типа после вызова функции (третий столбец):
В 13 версии результат корректный:
Функции to_date и to_timestamp научились понимать локализованные имена месяцев и дней недели. Раньше можно было использовать только английские названия:
Для соответствия стандарту SQL добавлена функция normalize(), нормализующая Unicode-строку, и предикат IS NORMALIZED, проверяющий, нормализована ли строка.
Подробнее о формах нормализации UNICODE.
Добавлен новый тип данных xid8 для 64-битного номера транзакции. Но нет, это не значит, что PostgreSQL перешел на 64-битные транзакции: все работает в точности как раньше. Но некоторые функции возвращают новый тип, например, теперь рекомендуется использовать pg_current_xact_id вместо старой функции txid_current, которая возвращала int8, и т. п.
Более того, типы anycompatible- и any- — это два независимых набора типов:
Процедурные языки
Простые выражения (как минимум не содержащие обращения к таблицам и не требующие блокировок) будут выполняться быстрее. Раньше в этих случаях время непроизводительно тратилось на обращения к планировщику на каждом цикле.
Вызываем slow_pi() в PG12:
Важные следствия этих изменений:
Индексы
Сжатие B-tree
Важный и долгожданный (работа началась аж в 2015-м) патч написанный Анастасией Лубенниковой (Postgres Professional) и Питером Гейганом (Peter Geoghegan) закоммичен, наконец, Питером. Об этом Настя успела рассказать на PGconf India. Postgres научился значительно сокращать размеры индексов B-tree за счет дедупликации, то есть экономии на повторяющихся ключах индекса. Эти индексы были серьезно переработаны для того, чтобы сжатие стало возможно без потерь в совместимости с предыдущими версиями индексов. Идея дедупликации взята из более гибкой архитектуры индексов типа GIN (обратные индексы — Generalized Inverted Index).
В этих индексах чаще, чем в B-tree, встречается ситуация, когда ключу соответствует большое количество записей. В случае обработки текстов, например, одна и та же лексема обычно встречается в нескольких документах. И она хранится в индексе только один раз. Этого индексы B-tree до последнего времени не умели.
Индексы B-tree отличаются от индексов GIN прежде всего страницами «листьев». В зависимости от количества записей, относящихся к одному и тому же значению ключа, возможны варианты: страница содержит только posting list — список TID-ов (идентификаторов индексируемых записей), если список мал, а если TID-ов много, то вместо списка значений хранятся новые «ветви деревьев» — ссылки на другие страницы типа posting list или другие ветви дерева (они называются posting tree).
Такая древовидная структура похожа B-tree, но отличается существенными деталями: например списки для перемещения по страницам одного уровня дерева в GIN однонаправленные, а не двунаправленные. Поэтому (в том числе) хорошей совместимости новых, дедуплицированных индексов со старыми версиями добиться непросто. И доработки действительно заняли больше 3-х лет. Надо было также отработать механизм очистки (микровакуум) и другие нюансы.
На тестах производительности все индексы, к которым дедупликация применима, сжались примерно в 3 раза. Сжатие дубликатов помогает и уникальным индексам, устраняя проблему распухания индекса при большом темпе изменений таблицы. Новое поведение можно будет подключать и отключать на уровне настройки индексов.
С новой оптимизацией сначала будет использовано более точное условие, позволяющее получить от индекса выигрыш, а затем полученные результаты будут перепроверены, чтобы учесть и другое ограничение. Сравните количество страниц, которые были прочитаны в версии 12 (Buffers):
с количеством буферов в новой версии:
С аналогичной ситуацией можно столкнуться и при использовании триграмм, и при проверке на вхождение массивов.
Параметры классов операторов
В PostgreSQL многие индексные методы доступа представляют собой “каркас”, который берет на себя высокоуровневую реализацию алгоритма поиска, работу со страницами и блокировками, журналом WAL. А привязка к конкретным типам данных и операторам выполняется с помощью классов операторов.
До сих пор классы операторов не могли иметь параметров. Например, для полнотекстового поиска может применяться GiST-индекс с классом операторов tsvector_ops (о классах операторов GiST здесь). Этот класс операторов использует сигнатурное дерево, а длина сигнатуры была фиксирована (124 байта). Теперь длину можно указать явно, что позволяет управлять балансом между размером индекса и эффективностью (числом хеш-коллизий):
Аналогичные изменения для начала сделаны и для других классов операторов GiST, в которых используется сигнатурное дерево, что относится к расширениям hstore, intarray, ltree и pg_trgm.
Но главная идея, ради которой затевалось это изменение, — возможность передать JSONPath-выражение в GIN-индекс, чтобы индексировать не весь JSON-документ, а только нужную его часть. Во многих случаях это позволит радикально сократить размеры индексов. Но эта работа еще предстоит.
Идея Олега Бартунова, реализация Никиты Глухова и Александра Короткова (все трое Postgres Professional).
Если наоборот, то всё ок:
Индексы GiST и SP-GiST будут ускоряться и на этой операции.
Обратите внимание, что в PG13, если спросить:
а если проделать то же в PG12, получим 20 записей: в 13-й версии список пополнился аж 8 операторами.
Это один из непрошедших патчей большой серии патчей JSONPath, который не успели доделать к выходу PG12. Часть стандарта JSON/SQL. Проблема была в том, что все функции серии патчей JSONPath являются immutable, но сравнение дат учитывает текущий часовой пояс, который может меняться во время сессии.
В таких случаях мы разрешаем существующим immutable-функциям выбрасывать ошибку про non-immutable сравнениях. В то же время в этом патче есть функции с суффиксом _tz, которые работают стабильно в операциях с timezone.
Вообще lax это нестрогий (в отличие от strict) режим работы функций с jsonb. В данном случае эта функция будет работоспособна в ситуации, когда один из аргументов, которые она принимает, равен NULL. В отличие от строгой версии — jsonb_set() — у нее есть дополнительный аргумент, который указывает на действия в случае NULL. Варианты: use_json_null / raise_exception / return_target / delete_key. Варианты предложены заинтересованными пользователями.
Оптимизировано очень много, главным образом усилиями Никиты Глухова (Postgres Professional). Но разбирать каждый пункт в данном случае бессмысленно: во-первых, изобилие их раздует и так не короткую статью; а во-вторых, изменения касаются внутреннего устройства, и не всякому пользователю это интересно. Поэтому лишь перечислим большинство из них:
Утилиты и расширения
pgbench
Утилита для запуска тестов производительности получила серию улучшений. Появилась статистика выполнения задач на фазе инициализации, более наглядный вывод, возможность посмотреть код встроенных скриптов, тестирование по секционированной таблице счетов.
pg_dump
Пользоваться такой выгрузкой следует осторожно. Далеко не факт, что данные нужно загружать на сторонний сервер. К тому же, вполне возможно сторонний сервер не будет доступен при восстановлении. Или сторонний сервер может разрешать только чтение, но не запись данных.
Серия небольших патчей делает работу в psql более комфортной:
libpq
reindexdb
pg_rewind
Ограничения утилиты понемногу снимаются, а возможности увеличиваются.
Во-первых, pg_rewind теперь может записывать информацию для восстановления (как это умеет делать pg_basebackup), а также запускать восстановление и последующую остановку экземпляра, если он не был остановлен через контрольную точку (раньше это надо было делать вручную).
А во-вторых, pg_rewind научилась работать с архивом WAL.
После того, как утилита находит точку расхождения WAL между двумя серверами, она должна построить список всех страниц, которые надо скопировать на целевой кластер, чтобы устранить различия. Для этого утилите требуются все WAL-файлы, начиная с найденной точки. Если необходимые WAL-файлы отсутствуют на целевом кластере, утилита раньше не могла выполнить свою работу.
pg_waldump
pg_waldump будет расшифровывать запись о подготовленной транзакции.
amcheck
Расширение amcheck научилось лучше распознавать повреждения в индексах типа B-дерево.
Кстати, теперь сообщения в журнале сервера о поврежденных страницах будут различаться для индексов и таблиц.
pageinspect
postgres_fdw
Суперпользователь на уровне сопоставления имен пользователей может разрешить обычным пользователям использовать подключение без пароля:
Это сделано в том числе и для того, чтобы в качестве параметров подключения можно было использовать sslkey и sslcert.
adminpack
Мониторинг
pg_stat_slru
В разделяемой памяти сервера находится не только большой буферный кеш, но и некоторое количество других, более простых, кешей (например, для статуса транзакций). Для них используется простой алгоритм вытеснения наименее часто используемых страниц (simple least-recently-used, или SLRU). До сих пор такие кеши “просто работали”, но назрела необходимость их мониторинга, в первую очередь для разработчиков ядра PostgreSQL, чтобы разобраться, нужно ли что-то в них менять. С этой и целью появилось новое представление pg_stat_slru.
pg_stat_activity
И еще два новых события ожидания, происходящих на реплике: RecoveryConflictSnapshot (конфликт с VACUUM, удалившем нужные версии строк) и RecoveryConflictTablespace (конфликт, связанный с удалением табличного пространства).
pg_stat_statements
До сих пор, расширение pg_stat_statements рассматривало запросы с фразой FOR UPDATE и без этой фразы как один и тот же запрос. Теперь запросы с FOR UPDATE учитываются отдельно.
Увеличилось и количество собираемой информации. Отныне фиксируется не только информация о ресурсах на выполнение команд, но и статистика по генерируемым журнальным записям. Новые столбцы представления: wal_bytes — объем сгенерированных записей, wal_records — количество сгенерированных записей, wal_num_fpw — количество полных образов страниц (full page writes).
Это стало возможным благодаря подготовленной инфраструктуре для отслеживания использования WAL. Поэтому теперь и EXPLAIN с новой опцией WAL будет показывать объем генерируемых записей:
Журнал
Ход выполнения
Новые представления pg_stat_progress_analyze и pg_stat_progress_basebackup позволяют отслеживать ход выполнения сбора статистики командой ANALYZE и создания резервной копии утилитой pg_basebackup соответственно.
Оптимизация
Вычисление на этапе планирования immutable-функций в предложении FROM
Патч Александра Кузьменкова и Александра Парфёнова (оба из Postgres Professional) помогает в случаях, когда в предложении FROM встречается вызов функции, фактически являющейся константой. В этом случае вместо того, чтобы выполнять соединение, значение константы подставляется в необходимые места запроса.
Вот как это происходит на примере запроса, связанного с полнотекстовым поиском:
Здесь нет соединения, а значение ‘tuple’::tsquery подставлено в запрос уже на этапе планирования. В версии 12 была совсем другая картина:
В случаях, когда необходима сортировка по многим ключам (k1, k2, k3…), планировщик теперь может воспользоваться знанием о том, что данные уже отсортированы по нескольким из первых ключей (например, k1 и k2). В этом случае можно не пересортировывать все данные заново, а разделить их на последовательные группы с одинаковыми значениями k1 и k2, и “досортировать” по ключу k3.
Таким образом вся сортировка распадается на несколько последовательных сортировок меньшего размера. Это снижает объем необходимой памяти, а еще позволяет выдавать первые данные раньше, чем вся сортировка будет выполнена полностью.
Например, в демобазе на таблице tickets есть индекс по столбцу ticket_no. Данные, полученные из индекса, заведомо будут отсортированы по ticket_no, поэтому следующий запрос будет использовать инкрементальную сортировку:
Функциональность инкрементальной сортировки можно отключить параметром enable_incrementalsort. В этом случае сортировка займет заметно больше времени:
Идею инкрементальной сортировки предложил еще в 2013 году Александр Коротков (Postgres Professional), и вот, спустя семь лет патч был доведен Джеймсом Коулманом до состояния, принятого сообществом.
Ускорение TRUNCATE
При TRUNCATE происходит сканирование shared_buffers для удаления буферов таблицы из общей памяти. Раньше сканирование выполнялось трижды, для каждого слоя таблицы: MAIN (основной слой данных), FSM (карта свободного пространства), VM (карта видимости). Сейчас логика изменилась, вместо тройной работы буферы сканируются только один раз. При больших значениях shared_buffers это даёт ощутимый выигрыш.
Частичная декомпрессия TOAST
Когда нет необходимости читать полностью TOAST, ограничиваясь его кусочком (slice) в начале или близко к началу, то и разжимать его полностью не имеет смысла. Сжатый TOAST читается итерациями: прочитали кусочек, если нужных данных нет, то разжимаем и читаем дальше. Предложено студентом Google Summer of Code Бинго Бао (Binguo Bao), который приводит пример:
С патчем на порядок быстрее:
Параллельный VACUUM
В своей статье на эту тему Егор Рогов подробно разъясняет этот важный шаг в распараллеливании. Вкратце: «Патч Масахико Савады, который позволяет выполнять очистку в параллельном режиме. Сама таблица по-прежнему очищается одним (ведущим) процессом, но для очистки индексов он теперь может запускать фоновые рабочие процессы, по одному на каждый индекс. В ручном режиме это позволяет ускорить очистку больших таблиц с несколькими индексами; автоматическая очистка пока не использует эту возможность.»
Автоочистка при вставке в таблицу
За этот патч (известный также и как Берсерк-автовакуум) нам надо благодарить Дорофея Пролесковского, который предложил решение следующей проблемы: автоочистка не приходит в append-only-таблицы, поскольку в них нет «мертвых» версий строк. Из-за этого не обновляется карта видимости, делая неэффективными только индексные сканирования (index-only scans), а когда очистка все-таки приходит для предотвращения переполнения счетчика транзакций, ей нужно одномоментно выполнить очень много работы. Теперь эта ситуация исправлена: автоочистка будет срабатывать и на добавление строк. Появилось два новых параметра сервера ( autovacuum_vacuum_insert_threshold и autovacuum_vacuum_insert_scale_factor ), аналогичные существующим для модификаций ( autovacuum_vacuum_threshold и autovacuum_vacuum_scale_factor ).
Оптимизация UPDATE для таблиц с генерируемыми столбцами
В версии 12 генерируемые столбцы пересчитывались при любом обновлении строки, даже если это изменение никак на них не влияло. Теперь они будут пересчитываться только в том случае, когда это действительно нужно (если изменились их базовые столбцы).
Использование нескольких расширенных статистик при оценке
В PG12 планировщик не умел использовать одновременно несколько расширенных статистик для одной и той же таблицы. Например, представьте ситуацию, когда построено две расширенных статистики по разным наборам столбцов, а в запросе участвуют столбцы и из одного набора, и из другого. Теперь планировщику доступна вся имеющаяся информация.
Инфраструктура для распараллеливания и COPY (см. также этот патч.)
Параллелизм в PostgreSQL все еще работает только для читающих запросов. С пишущими есть трудности, и одна из них — блокировки процессов, параллельно выполняющих одну задачу (входящих в общую параллельную группу). Считается, что блокировки таких процессов не конфликтуют — например, несколько процессов могут удерживать исключительную блокировку одной и той же таблицы. Это требует от разработчиков ядра особой аккуратности, но иначе постоянно возникали бы взаимоблокировками.
Но есть два исключения:
Для пользователя в общем-то ничего не меняется, но этот патч важен тем, что во-первых, прокладывает дорогу параллельным INSERT и COPY, и во-вторых, устраняет одно из узких мест PostgreSQL в условиях высокой нагрузки (о котором можно послушать в докладе HL++).
Безопасность
Простые числа EDH SKIP заменены
Речь об отказе от простых чисел EDH (Эфемерные ключи Диффи-Хеллмана) по уже не актуальному протоколу SKIP.
Мандатный доступ для TRUNCATE
Этот патч дает возможность расширениям встраивать мандатное управление доступом (MAC) для операции TRUNCATE. Права на нее теперь будут проверяться и расширением sepgsql. SELinux Reference Policy и дистрибутивы Linux, основанные на Redhat, не поддерживают проверку SELinux-м на db_table
Доступность значения GUC ssl_passphrase_command
Простой, но полезный патч. Теперь значение параметра ssl_passphrase_command будет видеть только superuser. Параметр задаёт внешнюю команду, которая вызывается, когда требуется пароль для расшифровывания SSL-файла, например закрытого ключа.
Локализация
Но это было только для ICU. Теперь номер версии хранится и для правил сортировки libc:
Что дает возможность выдавать предупреждения при изменении библиотеки в ОС. Очень актуально в свете перехода на glibc 2.28, где изменились многие правила сортировки, и соответствующие индексы следует перестроить.
Но пока на 2.28 не перешли, всё спокойно:
Полнотекстовый поиск
dict_int научился обращаться с абсолютными величинами
В словарь-шаблон dict_int (он же расширение) добавлена возможность убирать знак у числа.
То есть на этот раз распозналась абсолютная величина.
Секционирование
Поддержка секционированных таблиц в логической репликации
Раньше включение секционированной таблицы в публикацию вызывало ошибку:
Теперь это работает.
Улучшенный алгоритм посекционного JOIN-а
Начиная с 11-й версии планировщик умеет соединять секционированные таблицы посекционно, но только в том случае, когда границы секций в точности совпадают. Теперь алгоритм улучшен: он будет работать в случае, когда секция одной таблицы полностью входит в секцию другой, даже если их размеры не совпадают (например, если одна таблица секционирована по дням, а другая — по месяцам). Новый алгоритм действует для секционирования по диапазонам и по спискам.
tableam
В этой привлекательной и перспективной, но трудной области пока нет радикальных продвижений относительно PostgreSQL 12. Готовых подключаемых хранилищ типа zheap и др., отличных от heap) пока нет, но продолжается работа над API.
Более высокий уровень абстракции при определении размера таблицы
Робер Хаас (Robert Haas) переписал код, изменив его архитектуру в пользу абстрактных слоёв, чтобы не пришлось дублировать код в будущем. Данный кусок относится к estimate_rel_size — размеру слоёв (forks) таблицы.
Методам доступа таблицы можно использовать relcache
Этот патч приближает возможности управления памятью табличных методов доступа к возможностям методов индексных.
fsync
Защита от выставления неверных флагов для fsync()
Этот патч проверяет, выставлены ли правильно флаги при получении файлового дескриптора для fsync() — директории открыты только для чтения, а файлы для записи или для того и другого.
Резервное копирование и репликация
Пауза при восстановлении до достижения точки восстановления
Если при восстановлении закончились WAL-ы, а до указанного recovery_target_time так и не добрались, сервер завершает восстановление и переходит в обычный режим работы. Теперь будет не так. Процесс восстановления встанет на паузу, о чем сообщит в журнале, и у администратора будет возможность подложить недостающие сегменты WAL и продолжить восстановление.
Манифесты бэкапа
pg_basebackup теперь создает “манифест” — JSON-файл, содержащий информацию о сделанной резервной копии (имена и размеры файлов, необходимые WAL-файлы, а также контрольные суммы всего и вся).
Новая утилита pg_validatebackup проверяет резервные копии на соответствие манифесту, а также проверяет наличие и корректность необходимых для восстановления WAL-файлов с помощью утилиты pg_waldump (это относится только к WAL-файлам внутри самой резервной копии, а не в архиве).
Это позволит обнаружить ситуации, когда файлы резервной копии повредились либо исчезли, или когда восстановление стало невозможным из-за отсутствия нужных журнальных файлов.
Ограничение непрочитанных слотом репликации данных
Слот репликации — удобный, но опасный механизм: если клиент не будет вовремя читать данные из слота, непрочитанные WAL-записи могут занять все место на сервере. Теперь с помощью параметра max_slot_wal_keep_size можно будет устанавливать ограничение на максимальный объем дискового пространства, который может быть занят непрочитанными данными. Если при очередной контрольной точке оказывается, что размер превышен, слот инвалидируется, а место освобождается.
Windows
Поддержка Unix-сокетов на Windows
В Windows 10 поддерживаются unix-domain-сокеты, хотя и отключены по умолчанию.
Документация
В документации два новых приложения.
После долгого обсуждения появился Appendix M. Glossary. На текущий момент в глоссарии 101 термин.
Раз некоторые важные патчи не успели дозреть до PG13, можно ожидать, что PG14 окажется более радикальным шагом вперед. Прыжком, а не шагом. Увидим.
После апрельской заморозки кода работа над улучшениями в принятых в 13 версию патчей продолжилась и продолжается. Функционал некоторых описанных патчей изменился. Прочитать об этом можно в статье посвященной уже PostgreSQL 14.