Повреждение данных PostgreSQL на жестком диске. Что делать и как исправить?

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

Как Patroni решает проблему потери слотов логической репликации?

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

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

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

Временные таблицы как наследие перехода с MS SQL. Проблемы, оптимизация, подходы

Использование временных таблиц в PG несет дополнительные проблемы использования ресурсов сервера и скорости работы запросов. Но бывает, что без них никак не обойтись, особенно при миграции кода с MS SQL, если первичный код их активно использовал при наличии логики на уровне БД. Доклад посвящен проблемам использования временных таблиц при переходе с MS SQL и подходам к их решению стандартными возможностями PG в зависимости от сценариев в коде.

Работа с кодом PostgreSQL

Лет 7 назад я пришёл от разработки под Windows к непреодолимому желанию дописать некоторые части PostgreSQL. В этом докладе я бы хотел рассказать о деталях вещей, которые были мне не очевидны, когда я начал работать с исходным кодом, системой сборки и тестирования PG. Я собираюсь говорить о самых простых вопросах - рутинные задачи IDE, навигация, сборка и всё такое. И совсем не претендую на какой-то истинный путь. Возможно, что-то покажется совсем проблемами чайников :) Я был бы рад, если бы другие разработчики тоже поделились секретами своего разработческого быта. Можем устроить обсуждение grep vs IDE :)