Семейство jit_* закрывается тремя параметрами для тех, кто работает над самим JIT, а не с ним. Все три — логические, все по умолчанию выключены, все восходят к исходной работе над PostgreSQL 11 и все живут в разделе «Параметры разработчика». Что делает их достойными поста, так это то, что один из них действительно интересен, а два других демонстрируют контекст GUC, которого эта серия ещё не встречала.
Третий блок семейства jit_* — тот, который решает, когда JIT срабатывает, и именно здесь живут неприятности. Все три появились вместе с подсистемой в PostgreSQL 11, у всех трёх контекст — пользовательский, и все три выражены в единицах стоимости планировщика — той безразмерной валюте, привязанной к seq_page_cost = 1.0. Когда планировщик завершает план, он сравнивает общую оценочную стоимость плана с этими порогами и запечатывает результат в сам план. Стоимость выше jit_above_cost (по умолчанию 100000): компилировать выражения и деформирование кортежей. Выше jit_inline_above_cost (по умолчанию 500000): также встраивать тела встроенных функций и операторов, извлекаемые из биткода LLVM, установленного вместе с сервером. Выше jit_optimize_above_cost (тоже 500000): также прогонять дорогостоящие проходы оптимизации LLVM по результату. Установка любого из них в -1 отключает этот уровень; jit_above_cost = -1 отключает всю затею, поскольку два других уровня надстраиваются над первым.
Высокая доступность критически важна для сред логической репликации, но до недавнего времени переключение при сбое всё ещё могло оставлять подписчиков отключёнными от слотов репликации, от которых они зависят. PostgreSQL 17 решил это, представив синхронизацию слотов при переключении при сбое, что позволяет держать слоты логической репликации готовыми на резервных серверах и снижает потребность в полной пересинхронизации подписчиков после повышения.
PostgreSQL 19 развивает эту основу с помощью повторно-осведомлённой ручной синхронизации и более ясной видимости пропущенных попыток синхронизации слотов. В этой статье мы рассмотрим, как работают эти возможности и как вклад команды разработчиков PostgreSQL из Fujitsu помогает сделать переключение при сбое логической репликации более надёжным и простым в эксплуатации.
Узнайте, как PostgreSQL улучшает синхронизацию слотов при переключении при сбое для логической репликации, повышая надёжность и сокращая время простоя при переключениях.
Мы приступили к массиву к семейства jit_*, и здесь алфавит перестаёт быть полезным редактором. Строгий порядок поставил бы пороговые значения стоимости перед концепциями, которые они ограничивают, и оставил бы jit_provider в одиночестве на дальнем конце, поэтому для этого семейства мы идём логическими кластерами: сегодня переключатель и движок, затем пара, решающая, что компилируется, затем три порога стоимости, а отладочные переключатели — в конце.
Продолжая проходить семейство jit_* в логических кластерах: эта пара решает, что именно компилирует JIT, и вы уже видели их имена, потому что это те самые «Expressions true, Deforming true», напечатанные в каждом блоке JIT, который показывал прошлый пост. Оба — логические, контекст — пользовательский, по умолчанию включены, часть исходной работы над JIT в PostgreSQL 11, и помещены в раздел «Параметры разработчика» — раздел документации, который идёт с постоянным предупреждением «не для производственной базы данных».
Параметры io_*, которые мы рассматривали до сих пор, описывают сами запросы ввода-вывода: насколько велик каждый из них, сколько процесс может держать в полёте. Эти два решают, кто фактически их выполняет. Я писал об архитектуре и о том, что PostgreSQL 19 с ней делает, в статье AIO Grows Up; здесь — взгляд на уровне параметров, и он включает исправление того, что я там сказал.
effective_io_concurrency — это запрос. io_max_concurrency — это удовлетворение.
Новый в PostgreSQL 18 как часть подсистемы асинхронного ввода-вывода, io_max_concurrency представляет собой жёсткий потолок того, сколько операций ввода-вывода один процесс может иметь в полёте одновременно. Не на весь кластер; на процесс. Контекст — postmaster, поэтому для изменения требуется перезапуск, а значение по умолчанию — -1, что указывает PostgreSQL выбрать значение при запуске. Диапазон простирается до 1024.
Теперь мы вступаем во владения io_* — самую новую в пространстве имён GUC: ничего из этого не существовало до PostgreSQL 17. Если effective_io_concurrency отвечает на вопрос «сколько операций ввода-вывода мы держим в полёте?», то io_combine_limit отвечает на ортогональный вопрос: «какова величина каждой из них?» Глубина и ширина.
Автор Christophe Pettus: https://thebuild.com/blog/all-your-gucs-in-a-row-intervalstyle/
IntervalStyle — младший «брат» DateStyle, и он унаследовал семейную черту: он выглядит как предпочтение форматирования вывода, но также меняет то, как PostgreSQL разбирает ваш ввод. Мы рассматривали версию даты этого трюка в статье про DateStyle. Версия для интервалов менее известна и в одном конкретном случае более неприятна.
Когда вы работаете с базой данных, то часто выполняете несколько запросов, которые связаны друг с другом. Например, перемещение денег с одного счета на другой.
Каждое соединение, которое кто-либо устанавливал с сервером PostgreSQL начиная с версии 8.0, открывалось с того, что сервер без приглашения объявлял значение integer_datetimes. Начиная с PostgreSQL 10 объявляемое значение — это единственное значение, с которым вообще может быть собран сервер PostgreSQL, и текущая документация отделывается от всей темы одним предложением: «Начиная с PostgreSQL 10 это всегда on». Так что это пост о том, почему параметр ровно с одним возможным значением всё ещё представляется каждому клиенту в начале каждого разговора.
in_hot_standby — это лампочка, а не переключатель. Он сообщает, является ли сервер, к которому вы подключены, в данный момент горячим резервом: включён, когда ваша сессия работает на реплике, которая воспроизводит WAL и принимает запросы только для чтения (состояние, которое включает hot_standby), выключен на первичном сервере. Это логический параметр, он появился в PostgreSQL 14, и его контекст — ни один из обычных четырёх, потому что никто не может его изменить:
postgres=# SET in_hot_standby = off;
ERROR: parameter "in_hot_standby" cannot be changed
postgres=# ALTER SYSTEM SET in_hot_standby = off;
ERROR: parameter "in_hot_standby" cannot be changed
ignore_system_indexes завершает череду из трёх последовательных параметров с именем ignore_-что-то и с удобным отрывом является самым вежливым в этом семействе. ignore_checksum_failure и ignore_invalid_pages говорят PostgreSQL продолжать, несмотря на доказательства повреждения; этот же просто говорит ему перестать доверять набору путей доступа. Это логический параметр, по умолчанию выключен, и он живёт в редком контексте backend: его можно установить только до того, как сессия существует, либо в postgresql.conf (влияя только на новые сессии), либо во время подключения, что удобнее всего сделать как PGOPTIONS="-P", эквивалентный серверный переключатель. Установите его после подключения — и получите ошибку. Во всех поддерживаемых версиях это один из ровно двух параметров с таким контекстом (другой — post_auth_delay), он классифицирован как параметр разработчика и не появляется в образце файла конфигурации. Всё это — способ сервера сказать: вы не должны были это находить.
Никто не находит ignore_invalid_pages, читая документацию от корки до корки. Вы находите его, вставив PANIC: WAL contains references to invalid pages в поисковую систему, обычно в час, когда вы предпочли бы спать. Это параметр разработчика, отсутствующий в postgresql.conf.sample, присутствующий начиная с PostgreSQL 13. По умолчанию он выключен, а контекст — postmaster, что на этот раз ничего не стоит: сервер, который вам нужно было бы перезапустить, уже не работает.
ignore_checksum_failure — это не столько параметр конфигурации, сколько ломик в витрине за стеклом. По умолчанию он выключен, он вообще не появляется в postgresql.conf.sample (образец файла вежливо отказывается его рекламировать), и документация помещает его в раздел «Параметры разработчика», рядом с другими инструментами, которые вы надеетесь никогда не будете держать в руках. Контекст — суперпользователь, что означает, что суперпользователь (или роль, которой было предоставлено право SET на него, а такой роли не должно существовать) может переключить его в живой сессии командой SET; без перезагрузки, без перезапуска. Именно такая гранулярность и требуется для его единственного законного применения. Он появился в PostgreSQL 9.3 вместе с самими контрольными суммами данных: функция, которая проверяет, и рычаг, который отменяет проверку, родились вместе.
