19 мин

3K

Бета

PostgreSQL: PostgreSQL 19 Beta 1

Официальный релиз запланировали на сентябрь/октябрь. Вот что старейшины решили выделить в описании релиза 19-й версии:

Производительность

• PostgreSQL 19 усовершенствует асинхронную подсистему ввода-вывода, представленную в PostgreSQL 18: io_method=worker теперь автоматически масштабирует количество рабочих процессов ввода-вывода на основе новых параметров io_min_workers и io_max_workers.

• Расширение pg_plan_advice позволяет пользователям стабилизировать и контролировать решения планировщика, а pg_stash_advice - автоматически применять рекомендации, используя идентификаторы запросов.

• Autovacuum теперь может использовать параллельные рабочие процессы, которые можно настраивать с помощью нового параметра autovacuum_max_parallel_workers, а новая система оценки autovacuum помогает расставлять приоритеты таблиц при их вакуумировании. Кроме того теперь PostgreSQL помечает страницы как видимые, когда их запрашивают.

• Добавлена новая команда REPACK и ее неблокирующая опция CONCURRENTLY, которые позволяют перестраивать таблицы с меньшими операционными накладными расходами.

• PostgreSQL 19 увеличил производительность в 2 раза на INSERT при проверках внешних ключей. Также: новые оптимизации anti-join, более широкое использование инкрементных сортировок, "жадную" (eager) агрегацию, быстрое чтение из хранилища во время параллельных последовательных сканирований, упрощение IS DISTINCT FROM и IS NOT DISTINCT FROM до простых операторов <> и =, когда входные данные не могут быть NULL. Также есть улучшения для масштабируемости LISTEN/NOTIFY, которые влияют на многоканальные рабочие нагрузки.

Удобства для разработчиков

• На первое место в этом разделе поставили поддержку SQL/PGQ. Логично, такого ещё не было. Это не просто часть стандарта SQL:2023 ISO, это возможности удобной работы с графами, так актуальные во времена ИИ и анализа соцсетей. Об этом, например, здесь.

• Дальше - новые возможности темпоральных запросов: добавили поддержку UPDATE и DELETE для конструкции FOR PORTION OF.

• Добавили ALTER TABLE ... MERGE PARTITIONS и ALTER TABLE ... SPLIT PARTITIONS для упрощения реорганизации секционированных таблиц на месте. Появилась поддержка возврата строк, конфликтующих во время операции upsert, с помощью INSERT ... ON CONFLICT DO SELECT ... RETURNING.

• Новый синтаксис GROUP BY ALL упрощает добавление всех неагрегируемых и неоконных (non-aggregate and non-window) выходных столбцов в качестве части группировки.

• Для работы с jsonpath добавили функции lower(), upper(), initcap(), replace(), split_part() и семейство функций trim().

• Новая команда WAIT FOR LSN упрощает использование паттернов запросов типа "чтение своих записей" (read-your-writes) при работе с репликами: сеанс сможет ждать, пока изменения до определенной позиции в логе (LSN) не будут воспроизведены на реплике, а уже потом выполнять запрос SELECT.

• Добавили новые SQL-функции для получения DDL, необходимых для воссоздания ролей, табличных пространств и баз данных, что упрощает написание скриптов и миграций.

• Функция random() теперь работает с типами date и timestamp, а PL/Python теперь поддерживает событийные триггеры.

Безопасность

• С серверной поддержкой Server Name Indication (SNI) через новый файл pg_hosts.conf сервер PostgreSQL может предоставлять разные TLS-сертификаты в зависимости от запрошенного клиентом имени хоста.

Мониторинг и прозрачность (так я, не настаивая, предлагаю переводить observability)

• Статистику по типам блокировок можно увидеть в представлении pg_stat_lock, а детали операций восстановления в pg_stat_recovery. Столбец stats_reset теперь доступен во многих представлениях статистики, он показывает, когда счетчики были очищены в последний раз. Представления pg_stat_progress_vacuum и pg_stat_progress_analyze теперь включают столбец started_by, а pg_stat_progress_vacuum - столбец mode.

• Можно указывать уровни log_min_messages для каждого типа процесса. Количество байтов, записанных в виде полных страниц WAL, теперь выводится в лог VACUUM и ANALYZE, а EXPLAIN ANALYZE теперь показывает статистику асинхронного ввода-вывода (AIO) через опцию IO.

Логическая репликация и федерализация запросов

• Логическая репликация научилась реплицировать последовательности. Новый синтаксис CREATE PUBLICATION ... EXCEPT позволяет публиковать все таблицы в базе данных, кроме указанного набора, а CREATE SUBSCRIPTION ... SERVER позволяет определять подписки с использованием стороннего сервера (foreign server), упрощая управление учетными данными.

• Логическую репликацию теперь можно включать без перезапуска сервера - по мере необходимости, даже если параметр wal_level установлен в значение replica.

• Новый параметр effective_wal_level (доступный только для чтения) сообщает о текущем действующем уровне WAL - можно заранее не фиксировать более высокий уровень WAL для кластеров, который он может потребоваться лишь эпизодически.

• В postgres_fdw : вынос операций с массивами на удалённый сервер (pushdown), использование статистики с внешних таблиц для поддержки более качественного локального планирования запросов.

Ещё новое:

• Организационное: период бета-тестирования отныне включает временный режим grease mode (режим «смазки») для проверки проблем совместимости протокола в более широкой экосистеме. Об этом сделали специальную страничку в Postgres-wiki.

• Можно включать и отключать контрольные суммы без перезапуска или реинициализации кластера.

• JIT (Just-in-time компиляция) теперь отключена по умолчанию.

• Параметр default_toast_compression по умолчанию теперь установлен в lz4.

• Поддержка аутентификации RADIUS удалена.

• Команда vacuumdb --analyze-only по умолчанию теперь анализирует секционированные таблицы.

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

• PostgreSQL 19 Beta Release Notes

• Можно скачать отсюда

• О бета-тестировании

• Нерешённые проблемы

• Напишите о баге

• Дайте денег

Бета. Статьи.

Обзоры Павла Лузанова

Цикл статей-обзоров изменений 19 версии на основе коммитфестов. PostgreSQL 19: Часть 4 или Коммитфест 2026-01, а также 2025-11, 2025-09, 2025-07.

И не только

Среди других статей о новшествах версии есть такая:

Two Hundred and Twelve Things

Пишет Кристоф Питтус (Christophe Pettus) в собственном блоге The Build собственной консалтинговой компании с тем же названием. Его угол зрения - из коморки DBA. То, что наиболее важно для его работы. Поэтому о, скажем, графах он не пишет. Вот его топ для админов:

• Worker-managed AIO - пул потоков асинхронного I/O теперь масштабируется автоматически (io_min_workers, io_max_workers и др.) - настроил и забыл.

• LEFT JOIN → ANTI JOIN - планировщик чаще переписывает LEFT JOIN ... WHERE col IS NULL как анти-джойн - дешевле выполнение, особенно на больших таблицах.

• pgstattuple с потоковым чтением - диагностика состояния таблиц стала быстрее за счёт использования AIO/prefetch - можно запускать в рабочее время.

• Переход на стандарт C11 для сборки - важен для мейнтейнеров расширений. И об этом не пишет практически никто. А Кристоф посвятил пусть маленькую, но отдельную главку в статье. Итак: C11 полностью поддерживается всеми современными ОС (актуальные дистрибутивы Linux, macOS, BSD, а также RHEL 8 и новее). А вот на устаревших корпоративных дистрибутивах с компиляторами 2015 года и старше, в кастомных средах сборки для встраиваемых (embedded) систем, в сторонних (out-of-tree) расширениях, могут быть жестко прописаны флаги std=c99 в Makefile. Проверьте свои флаги сборки прямо сейчас, - советует Кристоф, - ибо лучше обнаружить эту проблему в мае, а не в октябре, когда вы уже пытаетесь запустить апгрейд на PG19.

PostgreSQL 19: Features I'm Excited About

Автор, Тяньчжоу (Tianzhou Chen, сооснователь и гендир шанхайской компании Bytebase, живёт, впрочем, в Долине) даёт свой список воодушевивших его новшеств. И он не повторяет буквально список в описании релиза. В нём, например, есть важное отличие: он пишет о фиче, чрезвычайно важной для российских разработчиков: о 64-битных идентификаторах. Как известно, в России много баз с огромной нагрузкой, которая привела бы к быстрому апокалипсису под красивым названием Wraparound. Российские производители версий Postgres сами приделывают 64-битные идентификаторы, но это не значит, что решение этой проблемы сообществом их уже не интересует. Наоборот. Пока там прошли только идентификаторы в MultiXact, но этот вопрос не заброшен, сражения архитекторов Postgres продолжаются. Итак, список:

• pg_plan_advice + pg_stash_advice,

• pg_get_*_ddl(),

• REPACK CONCURRENTLY,

• онлайн-включение контрольных сумм,

• pg_stat_lock, pg_stat_recovery,

• Синхронизация последовательностей в логической репликации,

• 64-битные MultiXact,

• Параллельный автовакуум.

Вот, кстати, недавняя статья о MultiXact.

Postgres as a Job Queue: The MultiXact SLRU Problem

Пишет Рич Йен (Rich Yen, инженер-сеньор в Microsoft). Копает глубоко. Почему использование PostgreSQL как очереди задач (SELECT ... FOR UPDATE SKIP LOCKED) ломается при высокой конкуренции: в механизме MultiXact SLRU при множестве параллельных блокировок одной строки инфраструктура локов не выдерживает. Возникает затор. Хотя дело не только в этом.

Мажорные релизы. Нейминг.

"Вот что я подумал: Postgres 9.6 у меня ассоциировался с 2016, и цифра «6» в конце и номера версии, и года всегда помогала мне запомнить год релиза. А запоминание важно, когда работаешь со множеством баз данных на разных версиях Postgres - это даёт понимание, насколько версия старая. И за последние 10 лет цикл релизов довольно стабилен: примерно одна мажорная версия в год. Поэтому, если бы следующая версия называлась 26 вместо 19, а следующая за ней - 27, было бы проще понять, насколько эта версия актуальна.

Ваш Nik.

То есть Николай Самохвалов (Nikolay Samokhvalov, postgres.ai). Пока идея всем (не очень известным) очень нравится.

UPD: откликнулся Том Лейн (Tom Lane): Geez, I thought we were permanently done with what-shall-we-call- the-next-release threads after we dropped three-part version numbers:

«Боже, я думал, что после отказа от трёхчастных номеров версий мы навсегда покончили с тредами в духе “как же назвать следующий релиз”.

Мне не нравится ни один вариант этого предложения, потому что я боюсь, что оно слишком сильно полагается на нашу способность строго придерживаться фиксированного релизного календаря. Что будет, если “v2027” сдвинется на 2028 год? Неужели тогда мы окажемся не в состоянии вернуться к обычному графику для следующего релиза?»

Другой классик - Питер Айзентраут (Peter Eisentraut) - поддержал его:

«К тому же, некоторые вещи, которые выходят под конец года N, по маркетинговым причинам выпускают уже как версию N+1.»

И Том добавил ещё одну пикантную добавку:

«Можно глянуть и с другой стороны: тут всплыла мысль на AI-секции на PGConf.dev: кто-то предположил, что ИИ может так ускорить наш цикл разработки, и можно будет выпускать по два мажорных релиза в год. Это не значит, что я в это верю. Но мы можем сами себе создать лишние обязательства».

Николай с готовностью принял конструктивную критику и сделал следующий ход:

«У меня есть ещё одно, гораздо более мягкое предложение. На самом деле — два.

1) Документация. Добавить что-то вроде: “Major version NN released YYYY, EOL Mon YYYY” прямо на таких страницах, как:

https://www.postgresql.org/docs/https://www.postgresql.org/docs/release/https://www.postgresql.org/docs/current/index.html

Сейчас, чтобы понять, насколько версия Postgres старая, приходится идти на https://www.postgresql.org/support/versioning/ и читать таблицу. А операторы, инженеры поддержки и вендоры, которые описывают совместимость, делают это постоянно. Если даты релиза и EOL будут прямо на главных страницах документации, один лишний переход просто исчезнет.

2) Год рядом с номером версии в анонсах релизов, новостях и пресс-ките. Вот так: PostgreSQL 19 (2026), а за ним логично последует: PostgreSQL 19, ежегодный мажорный релиз 2026. Это не привязывает версию к году - главным всё равно остаётся порядковый номер. Если релиз сдвинется, поменяется только год. А если цикл станет полугодовым, это просто и естественно превратится в “(2026.1)” / “(2026.2)” без всякой правки номера версии. То есть это не замена, а ещё один способ обозначения версии.»

Минорный релиз. Заплатки, принцессы, призраки

Выход беты, конечно, событие. Но очень предсказуемое, почти уже свершившиеся заранее. Ведь все изменения открыто обсуждаются, а многие и анализируются. А вот выход этого минорного релиза многих ошарашил.

PostgreSQL 18.4

(А также 17.10, 16.14, 15.18 и 14.23)

Этот минорный релиз удивительный, такого ещё не было. Поражает не коллекцией новых функций, а списком дыр, которые обнаружили и быстро залатали. 11 дыр!

• PostgreSQL 18.1 (2025) - 2 уязвимости,

• 18.2 (2026) - 5,

• 18.3 (2026) - 0 и

• 18.4 (2026) - 11.

В прежние годы доходило до 7:

• 9.3.1 (2013) - 7,

• 9.4.10 (2017) - 6, но считая расширения,

• 10.6 (2018) - 6.

И дело, конечно, не в том, что последние версии были плохие, неаккуратно написаны, хуже оттестированы. А в том, что для нахождения уязвимостей стали применять другие инструменты. И, конечно, ИИ. Радикально изменился список благодарностей: много новых имён. И, очевидно, демография радикально другая. Но сначала в 2 словах о каждой из 11.

Залатали дыры:

• CVE-2026-6472: PostgreSQL: команда CREATE TYPE не проверяет привилегию CREATE на схему при создании мультидиапазонных типов.

• CVE-2026-6473: (! "опасность высока") Целочисленное переполнение при выделении памяти в PostgreSQL.

• CVE-2026-6474: Утечка памяти через функцию timeofday().

• CVE-2026-6475: (!) Опасность перезаписи системных файлов через символические ссылки в pg_basebackup и pg_rewind.

• CVE-2026-6476: (!) SQL-инъекция в pg_createsubscriber через имя подписки.

• CVE-2026-6477: (!) Опасность перезаписи стека клиента через функции lo_* вlibpq.

• CVE-2026-6478: Раскрытие MD5-хэшей паролей через скрытый временной канал (timing attack).

• CVE-2026-6479: (!) Отказ в обслуживании (DoS) через неконтролируемую рекурсию при согласовании SSL/GSS.

• CVE-2026-6575: Функция pg_restore_attribute_stats в PostgreSQL принимает значения, из-за которых планировщик запросов читает данные за пределами массива статистики.

• CVE-2026-6637: (!) Переполнение стека и SQL-инъекция в модуле refint.

• CVE-2026-6638: SQL-инъекция в команде REFRESH PUBLICATION при логической репликации.

Опасность оценивалась по SVSS (Common Vulnerability Scoring System) версии 3.1 (см. NVD - CVSS v3 Calculator).

Разбирать эти 11 уязвимостей мы не будем: Кристоф Питтус (Christophe Pettus) разобрал их до нас в блоге своей консалтинговой компании The Build:

Eleven CVEs Walk Into a Release

Обратим внимание на вот что: атаки через рекурсию в CVE-2026-6479 - ого, такого в PostgreSQL не было.

Кого благодарить за бдительность?

Anemone, A1ex, Xint Code, Цзи Хэ Ван (Jihe Wang), Цзи Чжоу Фу (Jingzhou Fu), Павел Кохут (Pavel Kohout), Пётр Симечек (Petr Simecek), www.aisle.com, Брюс Дэнг (Bruce Dang, Calif.io) и Свен Клемм (Sven Klemm).

Имена звучат странновато, как-то не по-постгресовому, не правда ли? Анемон. A1ex. Xint Code.

Начнём с конца списка успешных дыроискателей: в Postgresso 7 (68) мы писали: pgspot 0.8.0 - это интересный инструмент для выявления уязвимостей в SQL-скриптах Postgres выложен на гитхабе Timescale. Автор - Свен Клемм (Sven Klemm) из Дрездена. Прежде всего pgspot призван выявить: атаки через search_path, создание небезопасных объектов."

Сейчас циферки версии подросли, хотя и не сильно: pgspot 0.9.2. Поддерживает по-прежнему svenklemm (Sven Klemm).

Девиз Calif: Хакеры уже идут вас хакать, готовьтесь! (Hackers gonna hack, be prepped). Они объявляют, что работают над обнаружением уязвимостей в коллаборации с Anthropic и их Клодом. Компания интересная, в ней даже Принцесса работает.

• Главный (не президент, не CEO, а просто Chief) - Тхай Дуонг (Thai Duong / 'thaidn', родился в Сайгоне.

• Ан Чинь (An Trinh - сооснователь и CTO выступал на конференции ZeroNights St. Petersburg - нет, это не в СПб, штат Флорида, это Питер, РФ.

• Михал Залевски (Michał Zalewski /lcamtuf) - советник-безопасник, автор утилиты afl-fuzz (AFL: american fuzzy lop), его вклад в искусство сокрушения софта "больше, чем всё вредоносное ПО за всю историю". Ушёл из Google и Snap, теперь пишет, исследует и "придумывает, как подготовиться к неизбежному Апокалипсису". Ну и:

• Париса Табриз (Parisa Tabriz) - "официальная Принцесса Безопасности в Google".

Уже неплохая складывается компания из душевных компаний. Но дальше - больше.

Павел Кохут (Pavel Kohout, Aisle Research). Он нашёл дыру в Графане (кстати, см. дальше о русской Графине) - Grafana Labs: Responsible Disclosure Recognition, в Апаче: Critical Apache HTTP Server Flaw Exposes Millions of Servers to Remote Code Execution Attacks.

И вот на что замахивается Aisle:

Платформа AISLE создана лидерами в сфере информационной безопасности и учёными в области ИИ, которые на собственном опыте видели и масштаб угроз, и ограниченность современных инструментов. Наша цель - не просто улучшить управление уязвимостями. Наша цель - ликвидировать бэклог. Ноль уязвимостей, доступных злоумышленникам.

• Главный по науке (и он у них идёт впереди CEO) - доктор Станислав Форт (Dr. Stanislav Fort). Теорфизик из Кембриджа, ИИ-исследователь с опытом работы в Google Brain, DeepMind и Anthropic.

• Гендир - Ондржей Влачек (Ondrej Vlcek), 20+ лет опыта в безопасности, и какого опыта! Он был гендиром Avast (Avast - хит 90-х), потом президентом Gen Digital. Получил учёную степень в Чешском Техническом Университете (Czech Technical University) в Праге.

• Джайя Балу (Jaya Baloo, COO & CISO - что это? А, это оперативное руководство и управление безопасностью). Пишут, что она входит в топ-100 мировых безопасников.

Дальше: Xint Code - леденящая душу история. Утилита Xint Code (с ИИ, разумеется) соревновалась с живыми искателями дырочек и нашла прославивший её баг CVE-2026-2005 в расширении PostgreSQL pgcrypto, который не замечали 20 лет. В самом PostgreSQL тоже нашли, но баг помоложе - CVE-2026-2006, его закрыли в 18.2.

Xint Code - это разработка компании Theori, ей лет 10, гендир - Брайан Сечжунь Пак (Brian Sejoon Pak), кореец. Он основал компанию вместе с Эндрю Уизи (Andrew Wiese, CTO), с которым закончил Карнеги Меллон. Сейчас в компании более 100 сотрудников. Офисы в Техасе (альма матер основателей - Карнеги Меллон - в Техасе) и в Сеуле.

На этом хакатоне ZeroDay.Cloud, где соревновались в исследованиях Postgres и MariaDB с помощью ИИ-инструментов, нашли 20-летнюю уязвимость. Нашли и те, что закрыли в 18.4 (CVE-2026-6473, CVE-2026-6474)

Хакатон организовала Wiz, Inc - израильско-американская компания в области облачной кибербезопасности, которая с марта 2026 года является частью Google Cloud: Google (Alphabet) приобрела её за $32 млрд в марте 2026 - крупнейшая сделка в истории кибербезопасности.

Вот отчёт Wiz: AI finds 20-year-old bugs in PostgreSQL and MariaDB на сайте CSO Online. Вот ещё заметка:

CVE-2026-2005: PostgreSQL pgcrypto heap buffer overflow leading to RCE | ZeroDay.cloud - На ZeroDay.Cloud 2025, Xint Code нашла 20-летней давности дыру с переполнением буфера в PostgreSQL-расширении pgcrypto.

Дальше: в списке уязвимостей есть серьёзная дыра CVE-2026-6475, её нашли с помощью Atuin Automated Vulnerability Discovery Engine. Это любимая игрушка Tencent Xuanwu Lab - команды XlabAI в составе Лаборатории Сюаньу (Tencent Xuanwu Lab).

На их гитхабе есть и вот что: Chat2DB - опенсорсная утилита, которая поможет:

• быстрее писать SQL-запросы,

• управлять базами данных,

• генерировать отчёты,

• исследовать данные,

• взаимодействовать с множеством различных СУБД (MySQL, PostgreSQL, H2, Oracle, SQLServer, SQLite, MariaDB, ClickHouse, DM, Presto, DB2, OceanBase, Hive, KingBase, MongoDB, Redis, Snowflake и другие) в едином интерфейсе.

Но сама Atuin Automated Vulnerability Discovery Engine на гитхаб не выложена.

На сайте XlabAI читателя главной страницы приветствуют такими словами:

"ИИ-агенты принимают решения от имени пользователей, однако эти решения не всегда безопасны. Мы выявили ряд распространённых рисков, связанных с принятием решений ИИ. Среди них выделяется категория рисков, способных оказывать устойчивое и скрытое воздействие. Мы назвали это явление „Призрачные зависимости“ (Ghost Dependencies)."

Существуют два Призрака. Имена их R1 и R2:

• R1 или Призрак Версии (Ghost Versions): У LLM есть дурная привычка предлагать устаревшие версии компонентов, которые часто встречались в их обучающих данных, вместо актуальных релизов.

• R2 или Призрак Имени Пакета (Ghost Package Names): LLM время от времени выдумывают несуществующие названия пакетов. Такие глюки зависят от архитектуры конкретной модели и поддаются прогнозированию.

Эти призраки, следовательно, молодые. Что же, команде слабо найти дыры 20-летней давности - как Xint? 20 - может быть, но 6-леток отлавливали: Deep Analysis of CVE-2019-8014: The Vulnerability Ignored 6 Years Ago.

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

Вообще, блог их интересный, есть даже про кванты: How Far Are Quantum Computers from Breaking RSA-2048?

В списке уязвимостей 18.4 есть ещё одна довольно экзотичная: timing attack: CVE-2026-6478 - Timing attack - по разнице в скорости ответа можно сделать выводы о внутренних данных системы, даже если прямого доступа к ним нет. Эта тема для Postgres и (СУБД тем более) не новая: 3 учёных мужа - Александр Рейсин (или Разин, Alexander Rasin), Джеймс Хербик (James Herbick), и Ник Скоуп (Nick Scope) из DePaul University и Бен Ленард (Ben LENARD) из знаменитой Argonne National Laboratory поднимали вопрос о Vulnerability of Access Control Restrictions to Timing Attacks in a Database Management System. А в 2021 на Database Administrators Stack Exchange обсуждалось: postgresql - Prevent timing attacks in postgres?

И так далее. Новые имена, новые компании, новые территории. И ясно, что это не всплеск, а новый поворот. Мир Postgres уже не будет прежним.

Теперь все будут соревноваться. Вот что предлагает G-рептилия:

Would Greptile Have Caught That Postgres Bug? - вставьте пулл-реквест (PR) на GitHub, в котором появилась эта ошибка, - без регистрации. ГРептилия пришлёт ревью старого пулл-реквеста, как если б он был новый, и покажет комментарии, которые Грептилия бы оставила.

Недавняя версия - 3-я: Greptile v3, an agentic approach to code review - Дакш Гупта (Daksh Gupta), сооснователь ГРептилии объясняет разницу 3-й версии и 2-й. Новая более склонна к рекурсии при обращении к LLM и подбору оптимальных инструментов внутри цикла. Дакш называет новый подход детективным.

Мы легонько касались Инженерии Хаоса в предыдущем Postgresso, даже доклад такой был: Chaos Engineering для тех, кто в гробу его видал - Лев Алимов, стафф-инженер в Т-Банке. А в предпредущем о китайских инженерах хаоса, даже о Chaos as a Service).

Больше хаоса! Звучит как "больше ада", но тут уж никуда не денешься. Его так и так будет много, это несомненно.

SQLsmith 1.5 - генератор случайных SQL для тестирования. Вот гитхаб. Автор - anse1/ = Андреас Зельтенрайх (Andreas Seltenreich 'anse1', Cybertec).

И мы говорили здесь о хороших ИИ-хакерах. А сколько на 1 хорошего приходится нехороших? Лучше об этом не думать.

В России эту тему тоже считают важной и актуальной. Tadviser, например, звал всех на семинар 8 июня 11:00: AI-SAST как новый слой анализа кода: где заканчиваются паттерны и начинается контекст. SAST это и есть Static Application Security Testing. На семинаре Антон Михайлов, директор по развитию группы продуктов SASTAV и Александр Заргаров, лидер технического контура безопасной разработки SASTAV рассказывали:

• Почему классический SAST остаётся фундаментом анализа и зачем вообще сохранять детерминированный движок.

• Где начинается «зона семантики»: почему IDOR (Insecure Direct Object Reference) нельзя найти простым поиском ID в URL.

• Почему нельзя просто заменить SAST LLM-моделью (и что сломалось бы в вашем Security Gate).

• Как работает гибридный подход.

• Как переход от «напиши правило» к «опиши риск» на естественном языке снижает порог кастомизации.

• В каких случаях AI-SAST не нужен (и почему массовые проверки лучше оставить классике).

Ладно. Добро в конце концов победит зло, вот и дыры в 18.4 закрыли (кстати, русская документация), а недавно вышла и Postgres Pro Standard 18.4.1. Enterprise выйдет попозже.

Минорный релиз. Кто.

Каждый 11-й участник разработки PostgreSQL 18 - сотрудник Postgres Professional - пишет CNews. А конкретно - 43 разработчика из примерно полутыщи тех, кого благодарят за выпуск PostgreSQL. Как подсчитали - очень просто. В компании пересчитали переданные сообществом медали (есть такая славная традиция).

Разработчики из Postgres Professional не одиноки в улучшайзинге PostgreSQL. Российские компании подтягиваются, прибавляют. Это заметно не столько по acknowledgements, сколько по переписке в hackers. Ещё недавно за Яндекс-облако отдувался многорукий Андрей Бородин (Andrey Borodin ), а за Тантор Лабс Илья Евдокимов (Ilia Evdokimov), а сейчас у них уже небольшие (до полудюжины), команды. Иногда промелькнут и почтовые адреса Сбертех или FTData, или вдруг РуТокен мелькнёт. Но, возможно, их больше, так как я сужу в основном просто по адресам, а у многих разрабов адреса не корпоративные.

Это поле деятельности - удивительное. Коллеги встречаются с бывшими коллегами, конкуренты не то, что доброкачественно конкурируют, они (пока) не конкурируют вообще - все просто делают общее дело (во всяком случае "я так вижу"). Возможно, скоро об этом будут вспоминать как о золотых временах и маленьком социальном рае. Возможно, компании далеки от критической массы, от порога радикального влияния. Мы помним, как жёстко покойный Саймон Риггс (Simon Riggs) продвигал MERGE, в котором был корпоративно заинтересован 2nd Quadrant, тоже, можно сказать, покойный (см. Битва при MERGE. Хроника с выводами и моралью).

Вообще есть такая страничка: Companies behind Postgres 18 development на ресурсе The Consensus. Проект Фила Итона (Phil Eaton), стартовал в этом году. И там мы видим, что в списке ведущих постгресовых компаний Postgres Professional уже не единственная российская: её поддержал Yandex.

Ну а Томаш Вондра (Tomas Vondra) доходчиво объясняет, как устроена кухня коммитфестов:

How Are Committers Selected?

Томаш говорит о демократизации процесса выбора новых коммитеров и отставки старых. Раньше этим занималась core team - горстка бояр, теперь - мини-сообщество коммитеров, служилое дворянство (простите за отсебятину). Коммитеров около 30. Но в любом случае это неформальные процессы, нигде жёстко не прописанные. Самоорганизация. Происходит всё примерно так:

1. Февраль–март: кто-то из коммитеров начинает обсуждение в закрытой рассылке.

2. Номинация: участники предлагают кандидатов, делятся опытом сотрудничества.

3. Обсуждение: аргументы за/против, оценка готовности.

4. Решение: достижение консенсуса, передача списка Core Team.

5. Приглашение: кандидат получает «commit bit» и доступ к закрытым ресурсам.

Что даёт статус коммитера:

• Доступ на push в основной git-репозиторий.

• Участие в закрытой рассылке (организационные вопросы).

• Доступ к внутренним инструментам.

• Но, ещё раз: никаких «секретных каналов» для технических решений нет - всё обсуждается публично на pgsql-hackers.

Разное

Новости vyruss.org

Это блог Джимми Энджелейкоса (Jimmy Angelakos), автора книги/курса PostgreSQL Mistakes and How to Avoid Them, где он систематизирует типичные проблемы в схемах, типах данных, безопасности и HA, даёт практичные рекомендации. В списке PostgreSQL: Contributor Profiles у него титул Significant Contributor.

Конечно, обладатель такой фамилии общается с греческими юниксоидами - с Αρχική Σελίδα | HELLUG. Конечно, russ к России отношения не имеет: ник, видимо, происходит от слова "вирус", где игрек - некоторый греческий флёр. Конечно, пишет он больше всего о собственных разработках - их есть у него: pg_statviz 1.0 released with AI-powered analysis.

Любит ездить по конференциям. Пишет любопытное о лоуландцах: PGDay Lowlands 2025 and Getting Postgres to the Next Level - прошла в Роттердамском зоопарке 12 сентября прошлого года. Докладчики докладывали морским черепахам, пингвинам и другой морской живности.

Но живёт он отнюдь не в средиземноморье. Живёт он рядом с хайландцами - в Эдинборо. Там, оказывается, тоже проходят Postgres-конференции и митапы:

Announcing the inaugural PostgreSQL Edinburgh meetup или

PostgresEDI April 2026 Meetup Recap & May Lightning Talks.

и вот: PostgresEDI · Календарь событий. Он же сам и организатор - их трое: ещё один Джим: Гарднер (Jim Gardner) и Денис Рыбальченко (Denys Rybalchenko). А спонсор - pgEdge.

Фокус моего внимания не случаен, но и не объективен: я просто влюблён в этот город из серого камня - строгий и совсем нестрогий одновременно. Это один из красивейших городов мира на мой вкус (может, прекрасней был Ангкор, но он давно зарос джунглями).

PGConf.Академия 2026

Пройдет 16 ноября, на этот раз не посреди тех-пустыря у Раменок, а в Центре Культур ВШЭ (Москва, Покровский бульвар, д. 11, стр. 6.). Организаторы - Postgres Professional и ФКН НИУ ВШЭ. Всё вокруг ИТ-образования: для преподавателей, методистов и экспертов из вузов, колледжей и профильных компаний. Для преподавателей (в т.ч. специализированных учебных центров) и сотрудников администраций вузов и колледжей - бесплатное. Для других категорий - платное.

Открыта регистрация, онлайн-формат участия тоже есть. Участникам конференции советуют дождаться подтверждения от организаторов по электронной почте.

The Rise of Experimental Data Lakes

Это не экспериментальные озёра данных, а озёра экспериментальных данных - если кто-то путает. Речь о научных данных. Которые теперь тоже решили заливать в озёра, а не пытаться собрать в одном водохранилище данных. Пишет Али Азхар (Ali Azhar).

How CERN Powers Ground-Breaking Physics with TimescaleDB

Tiger Data хвастается, и есть чем. Компании любят сотрудничать с ЦЕРНом, это престижно. Вот и Tiger Data устраивают совместный семинар с церновскими физиками:

• Рафаль Кулага (Rafal Kulaga, айтишник, CERN,

• Мартин Земко (Martin Zemko, айтишник, CERN,

• Брендон Пёрсел (Brandon Purcell), директор по продуктам, Tiger Data.

На этом примерно часовом вебинаре инженеры ЦЕРН расскажут, как они модернизировали свою устаревшую систему архивирования с помощью NextGen Archiver (NGA) и TimescaleDB (на базе PostgreSQL), чтобы повысить производительность, снизить затраты на хранение и упростить долгосрочную эксплуатацию. А именно:

• Построили модульную архитектуру архивирования (NGA) для модернизации устаревшего стека.

• Сократили объём хранения до 95% и ускорил аналитику по историческим данным до 40%, используя гибридную строково-колоночную (rowstore/columnstore) архитектуру TimescaleDB.

• Использовали непрерывные агрегаты (автоматически обновляемые материализованные представления) для создания быстрых дашбордов по огромным массивам исторических данных.

• Обеспечили работу со сложными метаданными, экономящими время, объединив реляционные данные и временные ряды в единой системе.

• Спроектировали решение с учётом сопровождаемости и гибкости, снизив зависимость от вендора и технический долг.

Хранилища - S3. По теме Workflow engines будут фигурировать Airflow, Nextflow и Snakemake.

В ЦЕРНе 800 с лишним SCADA (Supervisory Control And Data Acquisition = управление технологическим процессом и сбор данных) на базе сименсовских WinCC OA (SIMATIC WinCC Open Architecture). Системы Большого Адронного Коллайдера генерят сотни тысяч гигабайт данных в день. И эти данные существенно привязаны ко времени события.

Что за WinCC OA, с чем едят? Alexander Kuznetsov aka akcoun представляется в хабре как специалист по АСУ ТП - аббревиатура, которую подзабыли. Он предупреждает: в ряде моментов WinCC OA радикально отличается от обычных распространенных SCADA.

Swiss PGDay 2026

Пройдёт 25-26 июня в Рапперсвиле (Rapperswil). Это отнюдь не ЦЕРНовская тусовка, это немецкая Швейцария, недалеко от Цюриха, на берегу Цюрихского, а не Женевского озера. Устраивают конференцию прикладники: OST Eastern Switzerland University of Applied Sciences. Но в оргкомитете на самом почётном месте человек академический - Тобиас Буссман (Tobias Bussmann, Swiss Academy of Sciences, Bern).

Графиня (обещанная в 1-й половине обзора) - визуализация, мониторинг и анализ данных.

Российские разработчики (компания «Лаборатория Числитель») создали аналог Grafana под названием Графиня. И это не шильдик, - говорят они, - и не форк: решение вообще не использует код Grafana. Графиня предлагает:

• Стабильные обновления, которые не ломают дашборды.

• Упрощенную разработку плагинов.

• Многоуровневое кэширование.

• Универсальные API-контракты.

• Улучшенные функции администрирования и безопасности.

На этом пока всё.