PGConf.Russia 2025

В докладе расскажем о ручной миграции хранимых процедур и табличных функций из MS SQL Server в PL/pgSQL. Мы сознательно выбрали ручной перевод вместо использования расширений PostgreSQL с автоматической конвертацией. Причина — сложная бизнес-логика в коде T-SQL, для которой мы хотели получить чистый, читаемый PL/pgSQL-код.

В исходном T-SQL коде использовались:

• Комбинация хранимых процедур и табличных функций
• Табличные переменные и пользовательские табличные типы
• Рекурсивные Common Table Expressions (CTE)
• Опциональные параметры

Миграция потребовала:

• Приведения имен к стандартам PostgreSQL
• Переименования параметров и локальных переменных
• Маппинг табличных типов
• Маппинг табличных параметров в массивы
• Маппинг табличных возвращаемых типов в SETOF-запись
• Перевод логики между массивами и таблицами

В докладе мы пройдем путь миграции цепочки зависимых T-SQL-функций в PL/pgSQL, разберем особенности и обойдем подводные камни обоих языков

В любой бизнес-критичной системе возникает задача изменения структуры таблиц, например, добавление новых столбцов cо значением выражения, зависящего от других столбцов или превращение несекционированной таблицы в секционированную.

Если решать задачу реорганизации структуры больших таблиц стандартными средствами PostgresSQL, это вызовет большой downtime приложения — на всё время реорганизации таблица будет недоступна на запись, а в некоторых случаях и на чтение. 

В докладе автор представит dbms_redefinition — расширение собственной разработки, которое реализует функциональность, аналогичную одноименному пакету в Oracle, позволяет снизить до минимума (near zero) downtime на период применения к БД прикладных обновлений, меняющих структуру таблиц. 

В PostgreSQL данная технология отсутствует. Расширение pg_repack НЕ позволяет изменить структуру таблицы. Поэтому dbms_redefinition будет интересен всем пользователям СУБД, вне контекста миграции с Oracle. Я расскажу про использование пакета на примере реальной задачи, обсужу планы по развитию решения и добавление новой функциональности.

Если вы настраивали отказоустойчивый кластер Postgres, то сталкивались с необходимостью перенаправления пользовательского трафика на пишущий узел после аварии на основном узле и переключения на резервный. 

Скорее всего, для решения этой задачи вы настраивали дополнительное ПО, которое отслеживало состояние вашего отказоустойчивого кластера и перенаправляло трафик на нужный узел. Чтобы это ПО не превратилось в единую точку отказа, вы разворачивали дополнительную логику по обработке сбоев уже на этом слое. Кроме того, возможно, вы сталкивались с ограничениями Postgres по одновременной обработке большого количества клиентских сессий и с необходимостью пулинга запросов. 

Мы разработали расширение Proxima, которое снимает необходимость в настройке и администрировании дополнительного программного обеспечения. Proxima — масштабируемый, отказоустойчивый прокси-сервер и пулер соединений, способный перенаправлять трафик на пишущий узел, а при работе с BiHA переключение на новый пишущий узел в случае аварии происходит автоматически. 

В докладе я расскажу, как мы делали Proxima, какие архитектурные решения заложены в расширение, почему мы выбрали именно такой подход. Разберем тонкости реализации, которые позволили нам обрабатывать более 10 тысяч одновременных клиентских сессий. Рассмотрим примеры использования и ответим на ваши вопросы

Два года назад я рассказывал про запросы на получение данных — здесь библиотека LINQ to DB дает почти неограниченные возможности.
Этот доклад — об операциях модификации данных. LINQ to DB позволяет выполнять запросы UPDATE + JOIN, INSERT FROM SELECT, поддерживает оператор MERGE, блокировку на уровне строк SELECT FOR UPDATE, создание временных таблиц, имеет механизм скоростной вставки больших объемов данных.
Также расскажу про проект linq2db. EntityFrameworkCore — решение для тех, кто не готов уходить с EF Core и при этом хочет получить возможности LINQ to DB. Поделюсь опытом внедрения LINQ to DB в крупный проект.