Beta!

Это PostgreSQL 16 Beta 1. После неё будут ещё беты, число которых заранее не известно - по обстоятельствам. После появится релиз-кандидат, скорее всего тоже не один. Официальный релиз выходит обычно осенью. Можно заглянуть в Beta Testing в случае заинтересованности.

Конечно, практически всё новое, что появилось в бете, уже обсудили. В прошлом выпуске - Postgresso #4 (53) - было много ссылок на серии статей, в которых разбирались новые фичи. Это серия Мишеля Пакье (Michael Paquier) - PostgreSQL 16 highlights (за месяц коллекция пополнилась предикатами - JSON predicates); Павло Голуба (Pavlo Golub), у которого нового о 16-й не прибавилось; Лоренца Альбе (Laurenz Albe) - без новостей по 16-й; Крис Трейверс (Chris Travers) - тоже ничего пока нового по этой части; и у Хуберта 'depesz' Любашевского (Hubert Lubaczewski) в Waiting for PostgreSQL 16 тоже ничего нового.

И, разумеется, напоминаем о статьях-обзорах PostgreSQL 16, коммитфесты: Части

5 (2023-03 - ru, en - только что появился),
4 (2023-01 - ru, en),
3 (2022-11 - ru, en),
2 ( 2022-09 - ru, en),
1 (2022-07 - ru, en).

Что же выделяют в релизе сами авторы сообщения? Первым идёт производительность. Там много о параллелизме. COPY, например, сможет работать в 3 раза быстрей. Оптимизировали оконные функции. И есть любопытные штуки, ускользнувшие, кажется, от многих, анализировавших новости: появилась поддержка SIMD-команд процессоров x86 и ARM, которая ускоряет работу со строками ASCII и JSON, с массивами и поиск в подтранзакциях. Появилась балансировка нагрузки на уровне libpq.

Есть там целый раздел о логической репликации.

SQL/JSON тоже уделили внимание. Хотя и не целый абзац. Появились конструкторы (напр. json_array(), json_arrayagg(), предикаты IS JSON и др. (identity functions). Появилась необычная (но она есть в стандарте SQL) функция any_value().

Для любителей psql (а кто не любитель) появилась полезная вещь: поддержка расширенного протокола запросов (extended query protocol), а это значит, что можно подставлять переменные в подготовленный запрос: сказать SELECT $1 + $2, а потом\bind и подставить нужные переменные.

PostgreSQL 15.3

Бета бетой, а вышли и очередные стабильные релизы: PostgreSQL 15.3, 14.8, 13.11, 12.15 и 11.20. Главное: устранены 2 уязвимости, на одну из них указал Александр Лахин. Они описаны здесь:

Устранение уязвимости команды CREATE SCHEMA при внесении изменений в search_path (Александр Лахин)
Злоумышленник, имея привилегию CREATE на базу данных, мог выполнять любой код с правами суперпользователя. Проект PostgreSQL благодарит Александра Лахина за сообщение об этой проблеме. (CVE-2023-2454)
Исправление применения политик защиты на уровне строк после встраивания функции, возвращающей множества (Стивен Фрост, Том Лейн)
Если функция языка SQL, возвращающая множество, обращалась к таблице с политиками защиты на уровне строк и могла быть встроена в вызывающий запрос, эти политики защиты не применялись должным образом в некоторых случаях переиспользования кешированного плана другой ролью. При этом пользователь мог видеть или изменять строки, которые должны были быть невидимыми.
Проект PostgreSQL благодарит Вольфганга Вальтера за сообщение об этой проблеме. (CVE-2023-2455)

Эти проблемы актуальны для версий 11-15. Неподдерживаемые версии не тестировались, с большой вероятностью проблемы существуют и там. Кроме того исправлено более 80 багов во всех ветках релизов. Загляните в Release Notes и/или в Замечаниях к выпуску 15.3.

Драмы и боги форков. OSS. Нефоркнутые.

Больше форков богу форков

Владимир Медейко, ни много ни мало директор НП "Викимедиа РУ" [UPD: уже ушёл, теперь руководит собственным проектом - "Рувики. Свободная энциклопедия"], а из текста узнаём и о том, что Владимир работал в команде СУБД-круг Громова 2022 над Исследованием русских СУБД-вендоров, российское ПО базы данных, о котором мы, конечно, писали в предыдущем выпуске.

Он старается не повторять общие слова и мысли, а рассказать что-то новое и не совсем мейнстримное. Он ссылается на Формулировку четырёх свобод, но подробно говорит о 4-й: свободе вносить в код изменения и улучшения - именно она люба и желанна Богу Форков. А в ней - на возможности создавать именно коммерческие форки. Оказывается, что главку об импортозамещении в этом исследовании писал Владимир. И приводит оттуда цитаты о Postgres Professional и Arenadata. Упоминает и Символ импортозамещения маршрутизатор Маяк.

Это не статья, а небольшая заметка. Зато в ней есть голосовалка с такими вариантами ответов:

Пусть делают, чего хотят (с соблюдением лицензии), на то она и свобода-свобода!
Очень здорово, это позволяет СПО лучше развиваться и более широко распространяться.
Если отдают свои наработки обратно — хорошо, а те, кто только берёт — бяки.
Если форк тоже полностью под свободной лицензией — хорошо, иначе — резко против.
Несимпатичны, но пусть живут.

Так что там можно самовыразиться и посоревноваться в (нон)конформизме.

Заодно на тему Open Source: героиня недавней шербаумской Недели - Флоор Дреес (Floor Drees, Нидерланды) в своём интервью настойчиво рекомендовала книгу:

Working in Public: The Making and Maintenance of Open Source Software

Эту книгу написала Надя Эгбал (Eghbal, Nadia), она же Надя Аспарухова (Nadia Asparouhova - видимо, болгарско-турецких корней). Надя пишет не только об открытом коде. Её интересуют и популярные сейчас (и спорные) социо-философские концепции: Эффективный Альтруизм и связанная с этим Машина Идей. Так что наверняка и в Working in Public немало философских рассуждений.

Теперь о драме форков.

Гендир MariaDB Майкл Ховард (Michael Howard) сделал на их конференции OpenWorks в Нью-Йорке заявление, которое произвело впечатление. В его докладе немало любопытного, да это и не доклад: он зовёт на сцену полдюжины коллег.

На 5:35 этого видео Майкл призывает на сцену Курта Коловсона (Curt Kolovson), который был в 80-е ни много ни мало в знаменитой команде под руководством самого Майкла Стоунбрейкера в Калифорнийском Университете в Беркли. Но если смотреть/слушать лень, можно найти и что почитать, хотя пока текстовая информация скудная.

В своём мариядэбэшном блоге - This is a Blog for PostgreSQL Lovers - Курт пишет: Saying “yes” to MariaDB Xpand doesn’t mean saying “no” to PostgreSQL. И нахваливает Postgres, заметив, что масштабируемость и высокодоступность остаются его слабостями. Это его команда в MariaDB, куда Курт перешёл из VMWare, и решила поправить, создав Xpand (а Ховард в своей речи упоминает X-Project, имея в виду, судя по контексту тот же Xpand).

Xpand for Postgres (а есть ещё и Expand for MariaDB) реализована как расширение Postgres, причём это нефоркнутый (unforked - под этим подразумевается Postgres с неизменённым, непатченным кодом). Масштабируемость у Xpand не только по читающим, но и по пишущим транзакциям - это такой своеобразный мультимастер. Если распределённый движок (видимо, на базе приобретённой Clustrix) не может сам эффективно обработать запросы с неродным постгресовым синтаксисом, он передаёт их (pushdown) в Postgres. Xpand for PostgreSQL можно будет попробовать на Xpand4All как сервис SkySQL.

А в своём личном блоге на Medium Курт постит единственную статью - Weighing the Pros and Cons of PostgreSQL, где о Xpand нет ни слова, зато он перечисляет недостатки Postgres, выкатывает список его важнейших возможностей, которые могут быть реализованы только через расширения третьих сторон, и разбирает, почему (из-за каких несовместимостей) AWS Aurora и RDS, YugabyteDB, CockroachDB связаны с Postgres разве что по имени.

Новость произвела впечатление на присутствовавших журналистов. Они откликнулись.

MariaDB sticks PostgreSQL front end on SkySQL DBaaS

Статья редакции DUK News (это просто новостной портал, аббревиатура расшифровывается как Daily UK News) рассказывает об этом, кажется, наиболее подробно. Она же появляется на The Register за подписью Линдзи Кларк (Lindsay Clark) и с куда более эффектным названием:

MariaDB's Xpand offers PostgreSQL compatibility without the forking drama

Там говорится, что, де, эта игра изничтожит CockroachDB и переманит к себе пользователей гипермасштабируемых DBaaS. Там цитируют Доменика Равита (Domenic Ravita), очередного "евангелиста" той самой Cockroach, которую не ровён час убьёт новый проект MariaDB:

Я считаю, что если бы Майкл Стоунбрейкер стал переписывать сейчас PostgreSQL, он бы следовал тем же принципам, что и мы. Построил бы изначально распределённое решение, облачное, способное работать с разными облаками (multi-cloud) и многими регионами (multi-region), но при этом совместимое с PostgreSQL.

Можно также почитать и ещё на тему:

Распределенный SQL: альтернатива шардированию баз данных. Это перевод статьи Алехандро Дуарте (Alejandro Duarte) Distributed SQL: An Alternative to Database Sharding. В этой большой статье с множеством наглядных схем в качестве примера такой базы как раз приводится MariaDB Xpand (ex Clustrix).

А мы от форков плавно переходим к миграции - сначала между форками.

Миграция

Migrate from Redshift (на Hydra)

И то, и другое - форки PostgreSQL, и в том, и в другом колоночное хранение. Опенсорсная Гидра поддерживает heap-таблицы Postgres, индексы и секционирование. В Redshift код Postgres изрядно переработан, но всё же это Postgres. Redshift - в отличие от Hydra - не поддерживает табличные функции и триггеры. Ограничения (constraints) там тоже поддерживаются не полностью. Как и индексы (вместо них там есть DISTKEYS и SORTKEYS). И даже роли. В общем, это какие-то другие миры - для тех, кто привык к PostgreSQL (и к Postgres Pro). Такие вот форки.

Subtle Art of Code Conversion in Oracle to PostgreSQL Migration. | Database and Migration Insights

Дипак Махто (Deepak Mahto) исходит из собственного опыта миграции и примеры приводит тоже из своей практики. Одно утверждение весьма концептуально: делайте своеобразный обратный инжениринг кода - не конвертируйте механически строчку за строчкой, а сначала попробуйте понять: зачем код был написан именно так.

В примере он берёт код с иерархическими запросами и функциями обработки строк и заменяет код другим, использующим постгресовые regexp_split_to_array и unnest.

Как перейти с MongoDB на Postgres без простоев и сократить расходы на 30% - в блоге Southbridge опубликовали перевод большой статьи с сайта компании Voucherify: How We Moved From MongoDB to Postgres Without Downtime?

Автор статьи, Адриан Вильчек (Adrian Wilczek), подробно рассказывает о переезде. Перебирались они с SaaS-платформы Compose на Amazon RDS, используя DMS (Database Migration Service от AWS). План был такой:

проверка работоспособности данных в MongoDB;
создание дочерних таблиц с помощью Postgres Inheritance;
применение триггеров преобразования;
запуск сценариев Amazon Database Migration Service;
проверка работоспособности данных в дочерних таблицах;
перемещение «удалённых» данных из дочерней в родительскую таблицу;
переключение логики приложений на использование Postgres;
выявление аномалий;
перемещение «активных» данных из дочерней в родительскую таблицу;
остановка и удаление задач DMS.

Каждый пункт автор поясняет - некоторые подробней, с кусками кода, некоторые бегло. Результатом все остались довольны.

Как великану из страны 1С пересесть на слона?

Помечена как tutorial, автор статьи назвался так: @1CUnlimited.Начинается туториал с цитаты из интервью 2022-го года Ивана Панченко Инфостарту - PostgreSQL совершенствуется, и 1С тоже идет навстречу:

Для прикладного разработчика совершенно не важно, с какой базой он работает. Все эти вопросы решаются на уровне платформы. Миграция выглядит так — выгрузил базу в dt‑ник, загрузил его обратно в другую базу. Вот и всё.

Автора не удовлетворяет это "вот и всё". Как будет это работать с большими базами? Вообще-то, ограничения dt-файла заоблачны для реальных задач, да и база, прямо скажем, не то, чтобы гигантская - 1.7ТБ. И всё же. Автор, кстати, любит говорить о базах хоть и больших, но 1С БодиПозитив. В конце этой довольно большой и подробной статьи, в которой описывается даже выбор дня для переезда, говорится о перспективах шардинга. Со ссылкой на План разработок Postgres Professional.

Начавшись с цитаты из Панченко, статья заканчивается цитатой из Гёте:

Мечтай по‑крупному, мелкие мечты не зажигают сердца.

Dbmate 2.3

Инструмент миграции для больших коллективов разработчиков и нескольких продакшн-серверов. Никаких красот - командная строка. Можно использовать с Go, Node.js, Python, Ruby, PHP и др. Поддерживает СУБД MySQL, PostgreSQL, SQLite и ClickHouse. В тексте есть матрица свойств разных платформ разработки в разделе Alternatives.

pg-online-schema-change / pg-osc 0.8.1

Придумано для изменений схемы на продакшн с минимальными блокировками. Идея в создании "теневой" таблицы, в которой происходят нужные манипуляции, потом ей подменяют исходную. При этом используются триггеры.

Образование: Postgres-олимпиада

Как сообщает организатор фестиваля Дарья Рисухина (Postgres Professional), с 26 по 29 мая в Сочи прошел финал олимпиады IT-Планета 2023, в котором приняли участие 14 студентов и специалистов.

В течение 9 часов участники решали логические и практические задачи, связанные с разработкой нестандартных SQL-запросов. В режиме реального времени они отправляли ответы на проверку в систему и набирали баллы в зависимости от качества запроса. Всего было 7 задач.

?Первое место и ноутбук получила Дарья Рябова — выпускница НИУ «Высшая школа экономики»

?Второе место и смартфон забрал Ян Сенин — студент Белорусского государственного университета

?Третье место и умные часы выиграл Олег Крюков — аспирант Тульского государственного университета

Егор Рогов (отдел образования Poostgres Professional) прочитал доклад. Кроме того Postgres Professional провёл сертификацию на «Администратор PostgreSQL. Профессионал» в стенах Сочинского государственного университета.

AI, деньги, PgCat

Немало читателей не без оснований считает разговоры вокруг GPT суетой, а то и хайпожорством. Но правда и то, в сообществе этой темой очень даже интересуются. Вот, например, в постгресовой рассылке hackers появилась такая тема: vector search support, и этот не какой-то там вектор, а тот самый pgvector, который наверняка будут использовать прежде всего для машинного обучения. Ну и 5 млн. инвестиционных долларов в PostgresML - не миллиарды, конечно. Мелочь, но приятная. Поэтому несуетным читателям предоставляется возможность сразу перепрыгнуть в следующий раздел :)

Don’t use ChatGPT to solve problems

Кристоф Петтус (Christophe Pettus) Делится опытом в своём блоге:

Не надо бы этого говорить, но: не используйте ChatGPT как советчика в технических вопросах. Я задал ей 40 вопросов по PostgreSQL. 23 ответа были дезориентирующими или просто неправильными. Из них 9 могли как минимум вызвать проблемы с производительностью. Один из ответов мог привести к повреждению базы (с уничтожением файлов WAL для расчистки места на диске). LLM-ы (большие лингвистические модели) не замена профессионализму.

Но вот комментаторы не согласны, некто (робот/человек?) RobotAlly уточняет:

надо использовать GPT4, иначе этот эксперимент абсолютно бессмыслен. Тем более, через несколько месяцев [комментарий от 10 мая] они выпустят 4.5 или дадут доступ через API к вектроным базам. Но использовал ли Кристоф GPT4 - это так и осталось на 31-е мая непрояснённым.

Это предупреждение Кристофа не вразумило любопытствующих. Крейг Керстинс (Craig Kerstiens, Crunchy Data) раскладывает вопрос на 4 подвопроса в статье

Practical AI with Postgres

Можно ли использовать Postgres для создания ИИ-приложений? Безусловно.
Может ли Postgres стать автономной СУБД с ИИ? Возможно.
Стоит ли использовать ИИ для облегчения нахождения проблем (troubleshoot issues)? Может быть, но в самом критичном лучше полагаться на экспертов.
Остерегаться ли использовать ИИ, работая со своей базой? Отнюдь нет!

Он спросил: ты не могла бы помочь мне сгенерить схему Postgres для мультиарендного (multi-tenant) CRM-приложения?

Она помогла, создала 5 таблиц: одну - tenants - с id, а остальные получают tenant_id как внешний ключ, ссылающиеся на таблицу tenants. В 5-й таблице - deals, например, 10 полей и уже 3 внешних ключа - схема вполне ветвистая.

Крейгу особенно нравится, как GPT ловко генерит фейковые данные. Он её вежливо (говорят, это matters) попросил:

Не могли бы вы помочь мне сгенерировать некоторые записи для примера, подходящие к этой схеме данных?

GPT не отказала в любезности. Потом помогла с индексами и поработала в качестве help-а.

CRM, кстати, уже как-то публично строили при содействии ChatGPT:

Building an intelligent CRM using ChatGPT, PostgreSQL, and ToolJet, см об этом напр. в Постгрессо #3 (52). На хабре есть перевод этой статьи: Собираем CRM с помощником на ChatGPT.

Building AI-Powered Search using Amazon SageMaker and pgvector

Расширение pgvector сейчас явно самое практичное из всего, что ассоциируется с ИИ. В AWS это поняли, вот Кришна Сарабу (Krishna Sarabu, AWS) и приглашает строить эмбеддинги при помощи SageMaker - софта AWS для машинного обучения. Это практическое руководство - что делать на каждом шаге, как подключать соответствующие питонные Jupiter-ноутбуки и так далее.

И RDS стремиться не отстать:

Amazon RDS now supports pgvector for simplified ML model integration

То есть RDS научился хранить эмбеддинги ML-моделей и освоил поиск по ним.

Performance Tips Using Postgres and pgvector

Кристофер Уинслет (Christopher Winslett, Crunchy Data) понятно рассказывает о многих вещах, неведомых, скорее всего, тем, кто не интересуется ИИ и машинным обучением. В основном речь о настройке индексов - довольно специфических: ivfflat, использующих алгоритмы вычисления расстояний vector_l2_ops, vector_ip_ops, vector_cosine_ops. Соответственно, говорится и о настройке maintenance_work_mem и других параметров.

Idea for GPT Plugin: Citus Shard Key Selection in Postgres

От GPT-4 требуется помощь в правильном шардировании базы. Чтобы база работала быстро, нужно выбрать ключ шардирования так, чтобы коммуникации между узлами были минимальны, то есть, чтобы распределение таблиц по узлам физического кластера соответствовало типичной нагрузке. При этом в случаях OLTP и OLAP стратегия выбора этих ключей будет отличаться.

На разминке автор - aytekinar - беседует с GPT-4. Она демонстрирует адекватное понимание проблемы. В целом вывод таков: первые результаты очень даже обнадёживают, но надо отдавать себе отчёт, что ответы сети вероятностные и, следовательно, нужно ещё поработать для получения надёжных результатов.

В статье есть полезные (для интересующихся) ссылки:

Prompt Design (то есть как спрашивать)
Fine-Tuning (дообучение на специфических данных)
Chat Plugins (плагины OpenAI)

Ну а теперь о деньгах (last but not least):

PostgresML raises $4.7M to launch serverless AI application databases based on Postgres

Пишет сам Монтана Лоу (Montana Low, PostgresML CEO):

Наше облако - Serverless AI Cloud - на PG-коте! Это наш собственный балансировщик нагрузки, заточенный именно на наши нагрузки, характерные для машинного обучения, хорошо масштабируемый. Он умеет обслуживать много серверов и соединений, создавая сеть Postgres-кластеров, которые выглядят как независимые базы данных. Мы умеем масштабировать нагрузки отдельных арендаторов (tenants) на большой парк физических серверов, не ограничиваясь традиционной репликацией, используя и мощности многих GPU. За год существования PgCat научился работать в продакшн с сотнями тысяч запросов в секунду в таких компаниях как Instacart и OneSignal.

Кстати: вот серия статей Монтаны на тему AI. До этого мне в основном попадалась информация из PostgresML от Льва Кокотова aka levkk.

Но и PgCat интересен сам по себе и, чем дальше, тем о ПГ-Коте больше пишут и рассказывают. И на PGConf.Russia 2023 (см нашу статью о конференции) о нём часто упоминал Павел Конотопов в своём докладе Пять оттенков шардинга. Вот о последней версии Кота на их гитхабе:

PgCat 1.0: Modern Postgres Pooler and Proxy

А вот пишет о нём Фриц Хоогланд (Frits Hoogland, YugabyteDB):

pgcat: a PostgreSQL pooler

А вот Лукас Фиттл (Lukas Fittl, pganalyze) сравнивает его с самым мейнстримным балансировщиком-пулером - с pgbouncer-ом:

Postgres connection pooling: Comparing PgCat and pgbouncer

Это серия E60 его пятиминуток на youtube. И короткое описание.

Разное

How to submit a patch by email, 2023 edition

Питер Айзентраут (Peter Eisentraut) вспоминает, как в 2009-м написал в блоге How to submit a patch by email, пост имел успех и даже попал в PostgreSQL wiki. Тогда не наступила ещё эпоха Git и cfbot, поэтому Питер решил, что пора обновить тему. Ответ на вопрос, что в названии статьи, таков: используйте git format-patch. Вот Питер и рассказывает дальше, как использовать.

PostgreSQL compile times

Он же, Питер Айзентраут, сравнивает компиляторы: семейства gcc и clang разных версий и констатирует следующее: компиляторы работают всё медленней и медленней. Может и не стоит стремиться воспользоваться последними версиями. Ну а что gcc vs clang? Тут непонятно. Это зависит.

Experimental load balance setup based on shared-storage using pgpool and neon serverless

В этом что-то есть: Давид Ян (David Zhang) из канадского офиса китайской компании Highgo регулярно анализирует новые технологии, происходящие из базирующегося на Кипре стартапа Neon, основанного финном Хейкки Линнекангасом (Heikki Linnakangas) и Стасом Кельфичем, выпускником МИФИ. Но - ближе к технической стороне: в этой статье есть интересный поворот. Мы привыкли, что говоря о масштабировании, ограничиваются движением вверх (scale up). Здесь же говорится и о масштабировании вниз (scale down). Ведь в этом и есть суть serverless - не только наращивать мощность вместе с возросшей нагрузкой, но и отдавать ресурсы, когда нагрузка падает.

Multi-Dimensional Arrays in PostgreSQL

Лука Феррари (Luca Ferrari, напоминаем, что он адвокат OSS и человеческое существо) демонстрирует происходящее с многомерными массивами, вопрошая функцией pg_typeof(): кто ты? И оказывается, что даже многомерные массивы - это всего лишь плоские списки.

Table name as function arguments: a few checks

Это не статья, а кусок кода с некоторыми пояснениями. Лука Феррари нередко пишет динамический код, передавая функции название таблицы в качестве аргумента. При этом он всегда проверяет:

имеем ли мы дело с версией PostgreSQL 15 и старше, или с более ранней;
разбирает, передала функция полное имя или относительное;
существует ли уже таблица с таким именем.

PostgreSQL-Query-Lock-Explainer

Утилита, написанная на Python, показывающая блокировки, которые появляются в результате данного запроса. Интересно вот что: запрос выполняется, но не фиксируется. Происходит следующее:

BEGIN
-- запускается запрос
-- смотрим, что за блокировки появились
ROLLBACK

Эта утилита не предназначена для диагностики на продакшн. Автор - Адам Таль (Adam Tal).

How to Force a Join Order in Postgres

Лоренц Альбе (Laurenz Albe, Cybertec) начинает с того, что сообщество в целом хинты не приветствует: в огромном PostgreSQL TODO list их нет, а в дискуссии приводятся аргументы - почему хинты не нужны. Но Лоренц рад тому, что расширение pg_hint_plan существует, и показывает, как им пользоваться: как влиять на порядок соединений.

Кстати, pg_hint_plan - замечательное произведение NTT - входит в Postgres Pro Enterprise.

Но управлять можно не только хинт-планом. Можно для этого пользоваться CTE и настраивать join_collapse_limit.

От себя советуем обратить внимание на интереснейшие 2 доклада Павла Толмачёва на эту тему:

Коллапс в планах запросов. Достигаем и управляем (PGConf.Russia 2022) и Познакомимся с GEQO за 20 минут (PGConf.Russia 2023) - там тоже есть про join_collapse_limit и многое другое. Плюс интересные графики.

Running PostgreSQL on two ports

Кристоф Петтус (Christophe Pettus) понял, читая postgres-рассылки, что этот частный вопрос вполне актуален, и подытожил:

Можно навесить pgbouncer с включённой поддержкой TLS на другом порту и переадресовывать соединения к серверу PostgreSQL по локальному сокету.
Можно запустить stunnel, слушающий TLS-соединения и перенаправлять их в PostgreSQL.

И опять он, Booz

Что поделаешь, именно он организовал интересный и полезный моб. Вот, например, недавнее подведение итогов Майклом Кристофайдисом по поводу #008 pg_stat_statements.

Оказывается, у Райана есть календарь где расписаны ответственные за каждый каждую серию, постановщики вопросов - прошлые и будущие, до осени:

#001. Two truths and a lie - 7-го октября 2022 - Райан Буз (Ryan Booz);
#002. Backups - 4-го ноября 2022 - Андреас Шербаум (Andreas Scherbaum);
#003. What is the PostgreSQL community to you? - 2-го декабря 2022 - Пэт Райт (Pat Wright);
#004. PostgreSQL and Software Development - 6-го января 2023 - Генриэтта Домбровская (Henrietta 'Hettie' Dombrovskaya);
#005. Relational and Non-relational Data - 3-го февраля 2023 - Райан Ламберт (Ryan Lambert);
#006. A tip/hint/fact/something that you wish you’d known about PostgreSQL when you were just getting started learning it. - 3-го марта 2023 - Грант Фритчи (Grant Fritchey);
#007. Triggers: reading other opinions - 7-го апреля 2023 - Летиция Авро (Lætitia Avrot);
#008. pg_stat_statements 5-го мая 2023 - Майкл Кристофайдис (Michael Christofides);
#009. managing database changes - 2-го июня 2023 - Диана Фэй (Dian M. Fay);
#010. 7-го июля 2023 - Алисия Кучарчик (Alicja Kucharczyk);
#011. 4-го августа 2023;
#012. 1-го сентября 2023.

Заметьте, что Райан зарезервировал под номер вторнегов 3 разряда, то есть не собирается ограничиваться, видимо, 99-ю месяцами - размахнулся как минимум лет на 10. А кто он, собственно, такой? А это известно из интервью:

Interview with: Ryan Booz | PostgreSQL Person of the Week

Он из Центральной Пенсильвании, жену зовут Лаура, у них 6 детей, живут на ферме площадью 33 акра.

Из интервью можно, кроме всего прочего, узнать, что существует целый PG-гимн. Вот такой:

Гимн Вакууму

Варшавская юзергруппа поделилась гимном

Nothing Compares To VACUUM/The Ballad of Bloat

Исполняет Габриэль Кафа (Gabriel Cafa), слова здесь.

Postgresso №5 (54)