PostgreSQL *

В предыдущей статье я разобрал что умеет REDB на практике: code-first схемы, LoadAsync без Include, LINQ с оконными функциями, деревья, redb.Route и redb.Tsak. Если не читали — начните с неё, она даёт общую картину.

Теперь начинаю цикл «REDB изнутри» — серия статей про устройство хранилища: как хранятся объекты и свойства, как работают схемы и кэш структур, как LINQ превращается в SQL, как устроены деревья, права, оконные функции. Всё с реальным SQL под капотом.

Первая статья цикла — про саму базу данных. Без понимания схемы таблиц всё остальное будет висеть в воздухе.

Здравствуйте, уважаемые читатели Хабра!

В первой части мы рассказали, как решили задачу сегментации полигона дороги в PostGIS. А теперь рассмотрим сопоставление сегментов двух разных версий дороги для сохранения учёта историчности привязанных к ним событий.

Как удалённый пользователь получил appointment. И что это говорит о том, что значит «удалить» сущность в системе с soft delete.

Пользователь удалён. Appointment создан.

Для удалённого пользователя.

Контекст

Система клиники: пациенты бронируют слоты к врачам. Если слот занят — попадают в вейтлист. Когда appointment отменяется — первый из вейтлиста автоматически получает слот.

Удаление пользователей реализовано через soft delete: в таблице users есть поле deletedAt. «Удалённый» пользователь — это обычная запись с заполненным deletedAt. Физически запись никуда не исчезает.

Это стандартная практика: soft delete позволяет сохранить историю, восстановить данные, не нарушать foreign key constraints.

Мне нравится чистый SQL.

Не «нравится, потому что пришлось», а правда нравится. В хорошем SQL‑запросе видно, что происходит с данными: откуда берём, как фильтруем, где соединяем, что агрегируем и в каком порядке отдаём наружу.

Но как только в API появляются фильтры, сортировка, пагинация и отдельный COUNT(*) с тем же WHERE, чистый SQL быстро обрастает ручной бухгалтерией: args, placeholder«ы, fmt.Sprintf и копирование условий между запросами.»

В какой‑то момент я понял, что меня раздражает не SQL. Меня раздражает работа вокруг SQL.

Так появился qrafter — небольшой type‑safe SQL query builder для Go: без ORM, без codegen, с типизированными колонками, зависимым от диалекта рендером и обычным SQL + аргументами на выходе.

Telegram давно стал не только мессенджером, но и большой средой для сообществ: локальные чаты, профессиональные группы, каналы с комментариями, чаты по аренде, работе, продаже вещей, услугам и так далее.

В какой-то момент у нас появилась техническая задача: сделать систему, которая умеет читать сообщения из Telegram-групп, проверять их по пользовательским правилам и отправлять уведомления, если найдено совпадение.

Например, один пользователь хочет получать сообщения, где есть слова:

Если вы работаете с временными рядами в PostgreSQL, скорее всего сталкивались с необходимостью в выгрузке данных в Python, а потом как-то возвращали результат обратно. Это работает, но неудобно и медленно. Я написала расширение pg_stl, которое позволяет делать всё это прямо внутри базы — на нативном C, без экспорта данных наружу.

В этой статье расскажу, что это такое, как работает и почему это быстрее, чем подход с Python.

В проде connection pool редко падает громко — чаще он тихо превращает сервис в очередь ожидания: запросы висят, база задыхается, Kubernetes начинает перезапускать поды, а в логах всплывает знакомое Connection is not available.

В этой статье разбираем пять настроек HikariCP, которые чаще всего крутят «на глаз»: размер пула, minimumIdle, maxLifetime, keepaliveTime и connectionTimeout. Покажем, почему «поставить побольше» почти всегда плохая идея, как таймауты инфраструктуры ломают соединения и какие метрики стоит вывести в Grafana, чтобы увидеть проблему до инцидента.

Привет, хабровчане! Сегодня покажу, как писать расширения для PostgreSQL. На примере pg_plan_alternatives, который логирует все пути, рассматриваемые планировщиком. Вы увидите то, что обычно скрывает планировщик.

Типизированное хранилище для .NET поверх Postgres и MSSQL. C#-класс как схема — без миграций, без Include, с полным LINQ. Работает в проде.

Рассмотрим одну из старых проблем со стабильностью работы Postgres – отсутствие полного контроля за потреблением оперативной памяти при выполнении запросов. В ряде случаев это приводит либо к свопированию, либо к падению СУБД и остановке работы информационной системы. Происходит это неожиданно, без предупреждения и в не самый удачный момент. В системах 1С эта проблема точно существует, встречали не раз.

Вроде бы на помощь должна прийти технология OOM Killer Linux, но, как обычно, не все так радужно и есть неприятные нюансы.

В PostgreSQL процесс получения журналов walreceiver запускается на реплике только после того, как процесс startup применит все накопившиеся WAL. Это не создаёт особых проблем, если процесс startup успевает накатывать полученные журналы. Проблема проявляется, если используется реплика с отложенным применением журнальных записей, например, на сутки. Реплика не будет получать журналы сутки, слот репликации будет их удерживать на мастере.

Если процесс walreceiver остановится, то он не запустится до тех пор, пока не пройдёт время задержки, установленное параметром recovery_min_apply_delay. Команд ручного запуска процесса walreceiver нет. Получится, что сутки мастер копит журналы, только потом запускается walreceiver и начинает вытягивать журнальные файлы. Такое поведение нелогично, но его задокументировали: "When the standby is started and primary_conninfo is set correctly, the standby will connect to the primary after replaying all WAL files available in the archive. If the connection is established successfully, you will see a walreceiver in the standby, and a corresponding walsender process in the primary."

Всё время, до запуска walreceiver, слот репликации на мастере удерживает файлы журналов. На мастере скопится много журналов и, если не хватит места, то экземпляр мастера подвиснет по нехватке места в директории pg_wal (или слот инвалидируется по параметру max_slot_wal_keep_size и реплику придётся пересоздать).

Пятница, вечер. Один эндпоинт начал отвечать восемь секунд вместо двухсот миллисекунд, а в Grafana всё зелёное. PostgreSQL редко падает громко — он неделями копит мёртвые строки, лишние индексы и зависшие транзакции, пока не станет совсем плохо.

В статье — пять SQL-запросов из моего queries.sql, которыми я реально пользуюсь: bloat и dead tuples, топ тяжёлых запросов по pg_stat_statements, неиспользуемые индексы, висящие транзакции и блокировки. Работают на голом PostgreSQL 13+

Insol-1000 в сборе: центральный модуль с OLED и с модулями расширения на DIN-рейке.

Статья посвящена практическому построению распределённой системы автоматизации на основе открытого стандарта IEC 61499 и экосистемы 4diac (Eclipse Foundation).

Здравствуйте, уважаемые читатели Хабра!

В данной статье расскажем, как мы смогли автоматизировать процесс разбиения дорог в PostGIS, тем самым снизив нагрузку на специалистов и в разы увеличив скорость обработки полигонов.

Меня зовут Евгений Ефимкин, я руковожу группой Platform Reliability в Yandex Cloud. В числе прочего мы занимаемся безопасностью наших managed‑сервисов.

В managed PostgreSQL мы не выдаём клиенту привилегии superuser — иначе он сможет выйти за пределы своей базы прямо в операционную систему. Чтобы клиент при этом мог выполнять привилегированные операции: создавать базы, заводить роли, менять настройки кластера, — мы пишем сервисы Control Plane и выдаём специальные ограниченные роли (без выхода в ОС и без обхода проверок прав).

Несколько лет назад, занимаясь поддержкой логической репликации, я понял, что и этого мало: у PostgreSQL остаются места, где он сам, изнутри, выполняет код от superuser в обход всей конструкции. Дальше — два случая повышения привилегий у двух разных публичных облачных провайдеров. Оба вектора к моменту публикации закрыты — и в апстриме PostgreSQL, и у самих сервисов; оба провайдера своевременно проинформированы.

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

В данной статье будет описана структура PostgreSQL-базы данных и реализация данной задачи с помощью SQL в варианте PL/pgSQL. Реализация на Apache Spark будет описана в следующей статье.

В качестве примера будут созданы настройки распределения и входные данные для:

Разработчики не экстрасенсы: как мы перестали приносить им туман вместо ТЗ

Кейс про вагоны, Claude и то, зачем аналитику иногда полезно «потрогать» будущую систему до разработки.

Рабочая история команды аналитиков о том, как бизнес-фраза превращается в инженерный материал.

HTAP — одна из главных тем в мире СУБД. Вокруг PostgreSQL массово появляются конструкции с внешними аналитическими движками со своими моделями хранения данных и ограничениями совместимости, однако бизнесу не совсем комфортно жить в архитектуре, где транзакционные данные находятся в одной системе, аналитика — в другой, а между ними — разного рода ETL, CDC и прочие parquet‑файлы.

В Tantor мы движемся по иному пути, развивая HTAP внутри PostgreSQL, а не рядом с ним. Вокруг этой идеи строятся СУБД Tantor Polar и машина баз данных Tantor XData Gen3, в которой OLTP и аналитика, не теряя совместимости с Postgres, работают поверх общего хранилища данных и общей видимости транзакций. В этой статье хочется поговорить не столько о самом термине HTAP, сколько о том, как меняется архитектура PostgreSQL, когда OLTP и аналитика начинают работать поверх общего хранилища данных.

Практический разбор: запускаем PostgreSQL в Kubernetes с высокой доступностью, автоматическим failover и декларативным управлением - через один YAML-файл.

Кэш часто воспринимают как простой способ ускорить систему: положили данные ближе к приложению — получили быстрый ответ. Но на практике главная сложность начинается не с производительности, а с согласованности. Когда данные меняются, кэш может начать «врать»: показывать старые остатки, устаревшие статусы или разные версии одной и той же сущности разным пользователям.

В статье разбираем, почему инвалидация кэша — это архитектурная проблема, как TTL, события, CDC и lease‑подходы влияют на консистентность и когда кэш лучше вообще не использовать.