PG BootCamp Russia

За последние годы участники PG BootCamp Russia хорошо познакомились с «Тантор Лабс» — бессменным генеральным партнером конференции. Коллеги регулярно выносят на обсуждение новые архитектурные подходы и возможности для развития российских Postgres-технологий. В августе Tantor исполняется пять лет, а 10 сентября пройдет главное ежегодное мероприятие компании — Tantor JAM 2026.   Если вам интересны не только сегодняшние возможности PostgreSQL, но и технологии, которые будут определять его развитие в ближайшие годы, рекомендуем обратить внимание на это мероприятие.   Программа встречи формируется, однако уже проанонсировано несколько премьер: 🔹Новое поколение Платформы Tantor, основанное на AI-first подходе, — ИИ-администратор БД с целым роем специализированных ИИ-агентов, которые возьмут на себя рутинные операции по работе с СУБД.   🔹Реальные цифры по производительности МБД Tantor XData Gen3 на различных профилях нагрузки. Покажем, как enterprise-технологии, ранее доступные только в зарубежных решениях, — независимое масштабирование Compute и Storage, RDMA, распределенная файловая система и полноценный HTAP — становятся доступны в российском программно-аппаратном комплексе. Ранее подобное было доступно только в машинах класса Oracle Exadata. 🔹Подробнее будет рассказано о Tantor Polar — новой распределенной СУБД, открывающей следующий этап развития российских PostgreSQL-технологий с полным сохранением совместимости с экосистемой Postgres.   Ожидаются разнообразные демо, выступления руководителей разработки, прямое общение со специалистами компании, обсуждение того, куда движется отечественная PostgreSQL-экосистема, а также праздничная программа, посвященная пятилетию Tantor).     📅 Когда: 10 сентября, Москва (информация о площадке будет направлена зарегистрированным пользователям дополнительно). Формат: очный (требуется подтверждение организатора).   📌БЕСПЛАТНАЯ РЕГИСТРАЦИЯ

После мартовского PG BootCamp Russia многие темы, поднятые в докладах партнеров конференции, получают продолжение уже в отдельных технических мероприятиях.   🔹25 июня коллеги из «Хи-Квадрат» провели вебинар, посвященный развитию своих low-code инструментов для PostgreSQL. Если пропустили эфир — доступна запись.   Продолжает развитие и тема современной архитектуры PostgreSQL, которая звучала в докладах Вадима Яценко и Алексея Копытова. На московском PG BootCamp обсуждалось преодоление архитектурных ограничений классического PostgreSQL, подход Compute / Storage Separation и построение работающей на едином наборе данных HTAP-системы внутри PostgreSQL без необходимости прибегать к использованию внешних аналитических движков.   🔹30 июня в 11.00 команда «Тантор Лабс» расскажет, как эти архитектурные подходы реализованы в машине баз данных Tantor XData Gen3. В программе — эволюция архитектуры, 100% совместимая с PostgreSQL распределенная СУБД Tantor Polar, организация вычислительных и storage-ресурсов, инструменты управления и практическая демонстрация работы системы. Мероприятие пройдет онлайн бесплатно для всех участников.    📌Регистрация

Привет, это Павел Селезнев, участник команды Pangolin. Пару недель назад я выступил на PG BootCamp с докладом «Временные таблицы для PostgreSQL. Почему это важно для платформы 1С и что можно улучшить?». ⏯️ Запись доклада можно посмотреть по ссылке После выступления мне задали несколько интересных вопросов. На два из них я ответил в прошлом посте. Сегодня продолжу и разберу вопрос о медленной работе оператора UPDATE. Спасибо автору за вопрос и за то, что позже прислал почтой дополнительные детали 👍 Схема базы данных Таблица cmn_object (назовем её  «Справочник идентификаторов») CREATE TABLE cmn_object (     id bigint PRIMARY KEY );   Таблица od_structure_extension (назовем её «Справочником апартаментов») CREATE TABLE od_structure_extension (     id bigint PRIMARY KEY,     object_id bigint ,     common_apartment_number int NOT NULL );   Таблица _result (назовем её «Доступными апартаментами») CREATE TEMP TABLE _result (     identity_column bigint NOT NULL,     object_id bigint NOT NULL,     living_rooms_amount varchar(30) )   Проблемный запрос ----------------- Задача: требуется обновить те апартаменты, которые есть в _result и не заняты.   UPDATE _result r_u SET living_rooms_amount = ex.common_apartment_number::varchar FROM _result r JOIN cmn_object o   ON r.object_id = o.id JOIN no.od_structure_extension ex   ON ex.object_id = o.id WHERE r_u.identity_column = r.identity_column   AND r.living_rooms_amount IS NULL;   Проблема: запрос выполняется очень медленно. Уточним, что: 1) Проблема не относится к временным таблицам, если мы уберём ключевое слово TEMP, то она сохранится 2) Оптимизатор ошибается со статистикой, т.к. она не актуальна. Поэтому в начале здесь у нас происходит self join (то есть декартово произведение таблицы саму на себя), и далее идёт фильтрация миллионов строк.   ✔️ Возможные решения 1) Можно переписать запрос так:   UPDATE _result u SET living_rooms_amount = (     SELECT ex.common_apartment_number::varchar     FROM no.cmn_object o     JOIN no.od_structure_extension ex       ON ex.object_id = o.id     WHERE o.id = u.object_id     LIMIT 1 ) WHERE u.living_rooms_amount IS NULL   AND EXISTS (       SELECT 1       FROM no.cmn_object o       JOIN no.od_structure_extension ex         ON ex.object_id = o.id       WHERE o.id = u.object_id   ); 2) Если запрос редко выполняется, то можно запустить Analyze перед ним. Если вы тоже хотите узнать побольше по теме временных таблиц для PostgreSQL, задавайте вопросы в комментариях — разберу их там, а может, сделаю отдельный следующий пост 👌 Подписывайтесь на Pangolin в Max | ВКонтакте

Друзья! Видеозаписи докладов и фотоотчет с PG BootCamp Russia 2026 Moscow готовы. Для вашего удобства просмотр доступен на: 📌Rutube 📌Youtube Также доступен фотоотчет с конференции: 📌Облако с фотографиями Приятного просмотра!

🔹Вопросы к докладу Александра Никитина «Работа с логами PostgreSQL» ❔Используются в Вашей организации ИИ-агенты для анализа логов? Ответ: Нет, мы не используем ИИ для анализа логов ❔Отдел безопасности очень хочет видеть все изменения в БД, я смог им предложить только log_statements = all. Можно ли как-то этого избежать? Ответ: Если интересуют изменения, то всё-таки - log_statement=mod должно вам подойти - all будет включать в себя и запросы (SELECT), которые вряд ли будут интересовать безопасников. Возможно, отделу безопасности не хочется видеть абсолютно все изменения, а только изменения на каких-то конкретных таблицах? Ведь объём изменений в БД очень велик и со временем он начнёт превышать размер самой БД. Если можно ограничиться конкретными таблицами, то можно посмотреть в сторону дополнительных расширений типа pgaudit или рассмотреть создание триггеров, на интересующих их таблицах. В любом случае, нужно исходить именно от поставленной задачи. ❕Напоминаем: презентации спикеров уже доступны, а видео выступлений мы выложим и оповестим вас в ближайшее время.

🔹Вопросы к докладу Алексея Копытова «Разделение Compute и Storage: архитектурный прорыв для PostgreSQL в облаке» ❔Вопрос к слайдам 21/22. Зачем нужно было реализовывать fsync(), если на слайде 21 упоминается, что PolarFS работает в O_DIRECT режиме? Возможно, поэтому fsync() и был no-op? Ответ: Tantor Polar, как и PostgreSQL, для обеспечения долговечности данных вызывает сброс буферов на диск через аналог fsync() — в API PolarFS это pfsd_fsync() (и соответствующий вызов в libpfs). Без реальной реализации этого вызова нельзя гарантировать, что после сбоя питания или падения узла записанные данные действительно окажутся на постоянном носителе. В оригинальной открытой реализации PolarFS вызовы pfsd_fsync() и pfs_fsync() были пустыми операциями (noop): они ничего не делали. Причины в коде не задокументированы. Возможные объяснения - в облачной версии PolarFS поверх PolarStore запись могла считаться «автоматически устойчивой» (например, семантика вроде O_SYNC на уровне хранилища). Для блочного устройства (бэкенд PFS_DEV_DISK), которое мы используем, это не применимо. Или же разработчики могли считать, что раз PolarFS использует только небуферизованный I/O (O_DIRECT), явный fsync() не нужен. На деле O_DIRECT лишь обходит кэш страниц ОС и гарантирует попадание данных в кэш устройства, а не обязательно на энергонезависимый носитель. Считать запись устойчивой можно только если железо гарантирует защиту от потери питания (PLP), а в общем случае — и тем более в программно-определяемом хранилище — полагаться на это нельзя. Поэтому в нашей доработанной PolarFS исправлено: при вызове pfsd_fsync() / pfs_fsync() теперь принудительно выполняется сброс кэша записи нижележащего блочного устройства (аналог flush на уровне диска). Поведение включается опцией конфигурации diskdev_flush_enable (по умолчанию включено). Это даёт Tantor Polar корректную гарантию долговечности при использовании PolarFS на произвольном блочном устройстве или кластере хранения. ❔Если HAProxy знает кто мастер, и произошла потеря мастера, переключение на standby, может ли оказаться так, что бывший мастер, не имея связи с HAProxy, будет продолжать думать, что он мастер, и тажке проводить запись? Ответ: Patroni с DCS (etcd/Consul) – единый источник истины о том, кто сейчас мастер. Эпоха увеличивается при каждом failover. Shared storage с fencing – при переключении новый мастер получает эксклюзивное право на запись в общее хранилище. Даже если на реплике случайно или намеренно выполнить promote, эта операция провалится – реплика не сможет перемонтировать storage в режим RW, так как shared storage уже захвачен действующим мастером. HAProxy в этой схеме отвечает только за маршрутизацию клиентского трафика, но не за предотвращение split-brain – эту работу делают Patroni и shared storage. Так что потеря связи с HAProxy не позволяет старому мастеру навредить данным. ProxySQL с группой репликации – в нашей архитектуре мы используем ProxySQL, в котором группа репликации допускает только один пишущий узел. Роли узлов периодически проверяются в отдельном потоке мониторнга. Это гарантирует, что даже если какой-то узел по ошибке считает себя мастером, пишущий трафик на него не пойдёт. Таким образом, даже при полной потере связи между компонентами, ни один узел не сможет несанкционированно писать в данные.

Ответы на вопросы спикерам из чата онлайн-трансляции 🔹Вопросы к докладу Станислава Выщепана «Очереди и кэш на Postgres — без Redis, RabbitMQ и Kafka» ❔Вопрос по типам данных. Есть ли инструменты для работы с целыми числами больше 64 разрядов. Т.е. int, который больше, чем 2^64 (ограничение из-за разрядности архитектуры процессора). Речь об индексируемых данных. Ответ: тип numeric позволяет хранить и индексировать числа со 131 072 десятичными цифрами до точки. Для больших чисел придется отыскать или сделать расширение. ❔Сравнение ограничено только RabbitMQ и Kafka. Рассматривали ли Вы позиционирование PgSQL как замену инфраструктуры данными с ESB-решениями? Да/нет, почему, какие преимущества? Ответ: ESB — это зачастую сервер приложений, API которого может подстраиваться под целевые системы и преобразовывать данные между форматами разных систем. Реализация такого в Postgres видится не вполне целесообразной. 🔹Вопрос к докладу Константина Ващенкова «Опыт эксплуатации, проблемы и производительность PostgreSQL на Эльбрус, Baikal-S, Loongson/Иртыш, Repka Pi, x86» ❔Учитывает ли планировщик запросов PostgreSQL какие-то особенности архитектуры "Эльбрус" (например, очень большой набор регистров), или он работает в "эмуляции" x86, и мы теряем потенциал производительности? Ответ: вся инсталляция нативна, без бинарной транасляция, то есть чистый e2k. Потенциал производительности – да, теряем, но для этого существуют доработанные, т.е. не ванильные, версии PostgreSQL. 🔹Вопрос к докладу Кирилла Боровикова «Highload «из ниоткуда»: когда проблема не в СУБД, а в клиентской архитектуре» ❔В каком приложении ведется логирование процесса разбора проблемы? Чтобы можно было передать ссылку разработчику, который столкнулся с подобной ситуацией. Ответ: Процесс разбора обнаруженной ошибки или инцидента производительности ведется внутри нашего же продукта Saby, который сочетает функции как трекера, так и системы внутреннего документооборота.

Презентации спикеров PG BootCamp Russia 2026 Moscow Как и обещали, начинаем публиковать материалы с прошедшей конференции. Уже можно скачать презентации спикеров. Видео пока что загружаются, нужно еще немного подождать. 📑 Скачать презентации (GitHub)

PG BootCamp Russia 2026 Moscow: как это было 19 марта в Москве прошла пятая, юбилейная конференция PG BootCamp Russia. 563 участника офлайн и более 1300 онлайн — сообщество растет и укрепляется. О том, как это было – читайте на Хабре в репортаже одного из непосредственных участников события.. P.S. Записи всех докладов, а также фотографии с мероприятия появятся в ближайшие недели. Когда выложим - обязательно сообщим, оставайтесь на связи! Читать репортаж на Хабре

До розыгрыша «Кабанчика» осталось 3…2…1… Друзья! Состоялся розыгрыш книги «Высоконагруженные приложения. Программирование, масштабирование, поддержка» за авторством Мартина Клеппмана (в простонародии – «кабанчик») с автографами спикеров PG BootCamp Russia 2026 Moscow. Победителем стал Vitaly (@Vtitaly)! Поздравляем. Организаторы свяжутся с вами для уточнения деталей доставки.

У нас есть скромная добрая традиция – розыгрыш книги «Высоконагруженные приложения. Программирование, масштабирование, поддержка» за авторством Мартина Клеппмана (в простонародии – «кабанчик») с автографами спикеров PG BootCamp Russia 2026 Moscow. Для участия…

Всем привет! Мы разослали электронные сертификаты участникам PG BootCamp Russia 2026 Moscow. Направили их только тем, кто: — регистрировался на мероприятие — отметил, что хочет получить сертификат — присоединился к онлайн-трансляции Пожалуйста, проверьте почту (и папку «Спам» на всякий случай). Если сертификат не пришёл — напишите в комментариях, разберёмся 🙌

Один день, три потока, 25 докладов – и вот она, вся команда героев, благодаря которой этот день пролетел как один миг. Спасибо нашим спикерам, спасибо каждому, кто пришёл, слушал, спорил, задавал вопросы и делился опытом. Именно вы делаете PG BootCamp Russia живым и настоящим! 🫶🏻 👋🏻 До встречи на следующей конференции PG BootCamp Russia. Мы уже скучаем. Следите за новостями!

Уровни изоляции в PostgreSQL: аномалии, которые можно увидеть своими глазами Андрей Овчаренко на PG BootCamp 2026 вместо скучной теории устроил live-демонстрацию того, как работают уровни изоляции в реальной PostgreSQL. неповторяющееся чтение, фантомы — всё это было показано в живых psql-сессиях. Главное: • PostgreSQL не поддерживает Read Uncommitted — этот уровень работает как Read Committed. Так что грязного чтения вы не дождётесь. • Read Committed (по умолчанию) даёт хороший баланс, но внутри одной транзакции данные могут измениться — классическое неповторяющееся чтение. • Repeatable Read в PostgreSQL сильнее стандарта: он защищает не только от неповторяющегося чтения, но и от фантомов. Однако остаются другие аномалии. • Serializable — максимальная изоляция, транзакции выполняются так, будто идут одна за другой. Но плата — скорость работы и возможные ошибки сериализации, которые приложение должно обрабатывать. На демо было видно, как при Read Committed повторный SELECT возвращает свежие данные закоммиченной транзакции, а Repeatable Read «замораживает» снимок на момент первого запроса. Вывод: выбирайте уровень под задачу. Для большинства веб-приложений достаточно Read Committed по умолчанию. Если важна консистентность сложных отчётов — берите Repeatable Read. Для финансов — Serializable, но будьте готовы повторять упавшие транзакции. P.S. Запись live-доклада Андрея, как и всех остальных докладов, будет доступна через пару недель. 🌐 ССЫЛКА НА ОНЛАЙН-ТРАНСЛЯЦИЮ

🐘 «Тантор Лабс» на конференции PG BootCamp 2026 Moscow. Илья Рожнев и Александр Симонов рассказали, с какой болью столкнулись при масштабировании 1С. Аналитические запросы хочется скинуть на реплики, но PostgreSQL в режиме hot standby запрещает писать во временные таблицы. А 1С без них — как без рук. ▪️Решение: модифицировали исходный код СУБД, сняли блокировку, сохранив консистентность. Нагрузочные тесты с тысячами пользователей в реальной инфраструктуре подтвердили: работает, и ещё как! ⏱️ Скоро будет и видео их доклада

Привет с PG BootCamp, где Павел Селезнев выступал с докладом «Временные таблицы для Postgres. Почему это важно для платформы 1С и что можно улучшить?» В докладе затронул тему работы с временными таблицами — как и для чего они используются для платформы 1С. Показал статистику использования и обсудил, как можно улучшить работу с ними с точки зрения кода PostgreSQL. Запись доклада скоро опубликуем в нашем канале. Следите за новостями 😉