PGConf.Russia 2022

Более семи лет назад вышел PostgreSQL 9.4, в котором впервые появились функции логического декодирования и слоты репликации. И, спустя несколько лет, на базе этих функций в PostgreSQL 10 наконец то появилась поддержка логической репликации встроенная в ядро. Казалось бы, наступило солнечное будущее к которому мы так долго шли, если бы не пара неприятных моментов: логическая репликация не работает на репликах, плюс в PostgreSQL нет механизмов создания логических слотов на реплике. Это означает что при переключении мастера на новый узел слоты репликации теряются и на практике делает невозможным использование логической репликации и CDC для серьезных промышленных решений.

Postgres-hackers уже много лет пытаются найти решение данной задачи, но к сожалению большинство попыток и горяих дискуссий в рассылке не привели ни к чему конкретному. Но, оказывается в PostgreSQL 11 была добавлена одна маленькая функция, которая позволила решить проблему потери слотов логической репликации с помощью внешних инструментов.

В докладе я расскажу как Patroni решает данную проблему используя исключительно на возможности PostgreSQL. Мы поговорим о плюсах и минусах данного решения, и попытаемся понять безопасно ли это немного погрузившись во внутренности Postgres.

Любая СУБД хранит свои данные на жестком диске, следовательно, может произойти ситуация, когда данные на диске повредились. Это может быть сбой контроллера, логическое или физическое повреждение данных, есть и масса других причин. Хорошо, когда в таких ситуациях повреждается файл индекса, команда пересоздания индекса позволяет восстановить консистентность в СУБД. Гораздо хуже дело обстоит, когда поврежден файл таблицы или системного раздела, восстановить поврежденные данные тогда невозможно. Приходиться прибегать к разным ухищрениям. Это может быть восстановление из бекапа, копирование данных из поврежденной таблицы или другие способы. В докладе рассмотрим несколько случаев повреждения данных на диске и опишем варианты восстановления данных из поврежденных таблиц.

Я пересмотрел за жизнь много всякого кода, и очень часто встречал некоторый разнобой в обработке дат и времени: то у сторон не сходились отчеты за месяц, то суточные отчеты получались разные в Москве и Сан-Франциско, то еще чего-нибудь в таком же роде. Это не сказать чтобы сильно страшно, но довольно утомительно. Причина такого рода проблем всегда была связана с неаккуратной обработкой дат и времени. Тому, как этого можно постараться избежать, и посвящен мой доклад.

Расскажем о новых фичах SQL/JSON, принятых в 15-ю версию PostgreSQL. Покажем, как ими пользоваться, какие задачи они решают, и почему с ними лучше, чем без них. Полностью ли реализован стандарт SQL/2016 в части JSON? Тем временем, идет работа над следующим поколением стандарта SQL, где поддержка JSON развивается. Что там будет и как на это ответит Postgres ?