PGConf.Russia 2021

С начала 2021 года я исправляю редкий баг в CREATE INDEX CONCURRENTLY. Настолько редкий, что со времён появления в 8.2 я не нашёл его упоминаний. Тем не менее, наши системы этот баг аффектил часто, и я занялся его починкой. Так началась довольно длинная детективная история, в которой я узнал много интересных деталей и улучшил своё понимание транзакций в PostgreSQL.

Масштабируемые процессоры Intel® Xeon® третьего поколения - добавлены новые команды для ускорения DB: vector bit manipulation instructions для сжатия без потерь, векторные инструкции для ускорения протоколов типа TLS и SGX-анклавы для безопасного исполнения кода. И, конечно, новое поколение энергонезависимой памяти Intel® Optane™ 200 серии. Рассмотрим, что эти новые технологии и открытый инструментарий oneAPI могут дать проекту PostgreSQL.

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

Данных всё больше, диски всё быстрее, оптимизатор СУБД всё умнее, но проблема "распухания" остаётся крайне актуальной. Хочу поделиться своим опытом и подходом к борьбе с этим эффектом на большом количестве таблиц и данных в них.