В одной из производственных баз данных PostgreSQL 16.8 нашего клиента в журнале начала появляться ошибка, похожая на ошибку памяти:
ERROR: invalid memory alloc request size
Ошибка сразу указывала на двух вероятных виновников:
Исчерпание памяти
Повреждение памяти
Как оказалось, ни то, ни другое не было причиной. Вместо этого мы столкнулись с известной ошибкой PostgreSQL, которая заперла процесс контрольной точки (checkpointer) в бесконечном цикле повторных попыток. Единственным способом восстановления была принудительная перезагрузка, за которой последовало длительное воспроизведение WAL во процессе аварийного восстановления.
Эта статья объясняет, что произошло, почему ручные контрольные точки не могли это исправить, и как обновление до минорной версии PostgreSQL окончательно решило проблему.
Вы редко являетесь единственным, кто пишет ваш SQL. Ваша ORM пишет часть его, ваши вложенные представления пишут ещё больше, и рано или поздно одно из них соединяет таблицу саму с собой по её собственному первичному ключу. Это соединение возвращает ровно те строки, с которых началось. enable_self_join_elimination — это оптимизация PostgreSQL 18, которая замечает и удаляет такое соединение.
Недавно во время одной из миграций Oracle на PostgreSQL с корпоративным клиентом при разработке резервного модуля runbook мы оценивали шаги по выполнению сброса значения последовательности для соответствия исходному значению так, чтобы каждый новый запрос значения с использованием NextVal был новым и не приводил к сбою транзакций.
Это один из критических шагов любой миграции базы данных, т.к. в большинстве случаев последовательность LAST_VALUE не переносится в целевой объект неявно, а значения последовательности должны совпадать с источником, чтобы новая транзакция никогда не завершалась неудачей и приложение работало после переключения.
Мы использовали экспорт SEQUENCE_VALUES в ora2pg для генерации команд DDL, чтобы установить последние значения последовательностей.
enable_presorted_aggregate включён, он включён с момента появления в PostgreSQL 16, и самое полезное, что вы когда-либо сделаете с ним, — это отключите его ровно для одного запроса.
По умолчанию включён, контекст — пользовательский: может быть установлен для сессии, роли, базы данных или встроен в одну транзакцию. Последний вариант — это и есть вся рекомендация, так что запомните его.
«Собрат» параметра enable_partitionwise_aggregate, и он разделяет его определяющую черту: по умолчанию он выключен, и по той же причине. Поэтому, чтобы не повторять полностью аргументацию о том, почему он выключен по умолчанию, в этом посте рассматривается, что здесь отличается — механизм, преимущество, которого нет у версии для агрегации, и предусловие, достаточно строгое, чтобы быть главной причиной, по которой функция не срабатывает, когда люди её ожидают. По умолчанию выключен, контекст — пользовательский. Как и его «собрат», включение этого параметра — это реальное решение по настройке, а не диагностический зонд.
Один из действительно важных параметров секционирования, который стоит понимать, а не просто оставлять включённым, — потому что он выполняет свою работу в два разных момента, и разница между ними определяет, насколько он может помочь вашим запросам. По умолчанию включён, контекст пользовательский, и он относится к тому же семейству, что и enable_async_append: это диагностический инструмент, а не регулятор настройки. Это параметр, который позволяет PostgreSQL пропускать сканирование разделов, которые не могут содержать строки, нужные запросу.
Я являюсь фанатом последовательностей с тех пор, когда они появились в SQL Server 2012. До этого у разработчиков был выбор между столбцами IDENTITY и создания собственного механизма для таблиц.
Что такое последовательности в SQL Server?
Последовательности позволяют создавать привязанный к схеме объект, который не связан ни с какой конкретной таблицей.
Например, если у меня есть таблицы Sales.FlightBookings и Sales.VehicleBookings, и я хочу иметь общий BookingID, используемый как ключ для каждой таблицы. Если бы речь шла не только о BookingID, вы могли бы возразить, что существует проблема с нормализацией таблиц, но мы оставим это обсуждение на будущее.
Продолжить чтение "Как узнать последнее значение, используемое последовательностью в SQL Server"
Переключатель для параллельных запросов, уточняющий хэш-соединение из статьи про enable_hashjoin, и он требует точности, потому что «хэш-соединение, выполняемое параллельно» и «параллельное хэш-соединение» — это две действительно разные вещи. По умолчанию включён, контекст пользовательский, и он относится к тому же семейству, что и enable_async_append: это диагностический инструмент, а не регулятор настройки.
Оптимизация для секционирования и примечательное исключение в семействе enable_*: по умолчанию она выключена. Почти все остальные члены семейства по умолчанию включены и существуют для того, чтобы вы могли отключить возможность для диагностики; этот же по умолчанию выключен и существует для того, чтобы вы могли включить его, когда решите, что оно стоит затрат. Это обратное поведение — и стоимость, которая его мотивирует, — составляют суть данного поста. Контекст — пользовательский. И в отличие от большинства членов семейства, изменение этого параметра — это легитимное решение по настройке, а не просто диагностический зонд.
Автор: Christophe Pettus, All Your GUCs in a Row: enable_parallel_append
Возвращаемся к параллельным запросам и параметру, который легко спутать с первым в этом семействе. enable_async_append был посвящён параллельному выполнению внешних сканирований на удалённых серверах. Параметр enable_parallel_append касается параллельного выполнения локальных дочерних узлов Append на рабочих процессах. Разный механизм, другая задача, похожее название. По умолчанию включён, контекст пользовательский, и он относится к тому же семейству: это диагностический инструмент, а не регулятор настройки.
Недавно я помогал заказчику расследовать проблемы с базой данных. Оказалось, что эти проблемы тянутся от слишком большого количества таблиц в базе данных. Поскольку это для многих может стать неожиданностью, я решил, что стоит написать об этом.
Последний из трёх переключателей стратегий соединения и в некотором смысле самый важный, потому что вложенный цикл (nested loop) — это одновременно и простейшее соединение в PostgreSQL, и источник самого печально известного катастрофического падения производительности. Три алгоритма были представлены в статье про enable_hashjoin; этот пост завершает серию. По умолчанию включён, контекст — пользовательский, и он относится к тому же семейству, что и enable_async_append: это диагностический инструмент, а не регулятор настройки.
Второй из трёх переключателей стратегий соединения. Три алгоритма были изложены в статье про enable_hashjoin — вложенный цикл, соединение слиянием и хэш-соединение, — так что здесь мы углубимся в средний из них. По умолчанию включён, контекст — пользовательский, и он относится к тому же семейству, что и enable_async_append: это диагностический инструмент, а не регулятор настройки.
Обновление кластеров PostgreSQL 19 стало более плавным благодаря таким инструментам, как pg_upgrade и pg_createsubscriber, которые вместе обеспечивают обновление с практически нулевым временем простоя, сначала преобразуя физические реплики в логических подписчиков, а затем выполняя обновление с минимальным прерыванием обслуживания.
Однако этот подход обнажает давний пробел в логической репликации: состояние последовательностей (sequence state) не реплицируется.
В этой статье мы рассмотрим реальный сценарий обновления, покажем, где именно всё может пойти не так, и объясним, как новая функция синхронизации последовательностей в PostgreSQL 19 делает весь процесс безопасным для промышленной эксплуатации.
Узнайте, как PostgreSQL 19 улучшает процессы обновления благодаря внедрению синхронизации последовательностей, обеспечивая безопасные и бесшовные переходы при обновлении баз данных.
