Как перестать бояться обновлений glibc

PostgreSQL использует системные библиотеки правил сортировки, например, glibc или ICU, для расположения текста в определённом порядке. Общеизвестно, что необходимо принять меры предосторожности на случай, если библиотека изменит порядок сортировки для какого-либо правила. Любой индекс, который использовал старый порядок, вероятно, будет повреждён после установки новой версии библиотеки.

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

Сколько нужно инженеров, чтобы скобки заработали?

Недавно появившийся в PostgreSQL, jsonb subscripting не выглядит так же захватывающе, как другие улучшения в jsonb. Но те изменения, которые видны пользователю - всего лишь верхушка айсберга. Как много людей было вовлечено в разработку, и какие решения были сделаны в дизайне? Как много времени это заняло, и какие хорошие/плохие идеи существуют для продвижения патча? Эти и несколько других вопросов будут целью это презентации.

История одной миграции

В данном рассказе мы хотим рассказать о том, как команда Microsoft, созданная из двух различных команд, работала над проектом, решала проблемы миграции, используя ora2pg, и смогла доказать, что Postgres Single Server может демонстрировать хорошую производительность наравне с Oracle Exadata. Мы расскажем о наших методах работы, а также о ряде основных проблем технического характера, с которыми мы столкнулись, включая миграцию выражений BULK COLLECT, иерархических запросов, курсорных выражений REF CURSOR и других, более сложных конструкций Oracle.

Наша история о практическом подтверждении гипотезы, которое доказало, что Postgres может демонстрировать такую же производительность, как Oracle Exadata. Схема мигрируемой БД была не самой простой. Скорее, наоборот. Код был нагружен динамическими запросами, выражениями BULK COLLECT, вложенными циклами, операторами CONNECT BY, глобальными переменными и множеством зависимостей. Инструмент Ora2pg очень помог нам с преобразованием схемы БД, но всё равно осталось много работы, которую можно было сделать только вручную. Оценки, которые мы получили благодаря инструменту, также оказались очень далеки от истины, поскольку требовалась не просто миграция кода, а изменение его архитектуры. В рамках нашего доклада мы рассмотрим следующие подтемы:

• Как (не) работают оценки
• Как мы справились с миграцией выражений BULK COLLECT
• Почему мы избавились от выражений REF CURSOR
• Как мы застряли на фазе тестирования одного из пакетов и как помощь друга помогла нам в решении этой проблемы.
• Как мы справились с иерархическими запросами и детализацией иерархии

Архитектуры с Postgres в продакшне

При использовании PostgreSQL в продакшне крайне важно реализовать стратегию высокой доступности. В случае с сервисом БД требования к высокой доступности будут касаться как самого сервиса, так и набора данных.

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