Двенадцать параметров имеют префикс debug_, и этот префикс является значимым: это собственные средства разработки и контроля качества PostgreSQL, предоставленные в виде настроек времени выполнения, чтобы сборочная ферма (buildfarm) и разработчики ядра могли тестировать пути кода без перекомпиляции. Pavlo Golub, пишущий об одном из них, подвёл итог правильному подходу: «Я никогда-никогда не буду трогать параметр времени выполнения с префиксом “debug” в своих производственных кластерах». В основном это правильно. Давайте разберём дюжину параметров и то, что они на самом деле дают, потому что один или два тихо полезны, а остальными стоит восхищаться с безопасного расстояния.
Кластер параметров на букву B меняет направление: от разовых странностей к параметрам фонового процесса записи (background writer), которых насчитывается четыре GUC. Первые два мы рассмотрим как пару, потому что bgwriter_delay знакомит нас с самим процессом, а bgwriter_flush_after органично вписывается в экскурсию по механизму writeback из статьи про backend_flush_after.
Параметр для разработчиков (developer option) и действительно полезный. backtrace_functions принимает разделённый запятыми список имён внутренних C-функций; если ошибка возникает внутри любой функции из списка, PostgreSQL записывает трассировку стека на уровне C (C-level stack trace) в журнал сервера вместе с ошибкой. Добавлен в PostgreSQL 13. Значение по умолчанию — пустая строка. Контекст — superuser (или любой пользователь с соответствующим привилегией SET). Доступен не на всех платформах, и качество вывода зависит от того, как был скомпилирован PostgreSQL.
Это необычная область для оператора — это параметр для исследования исходного кода самого сервера, когда что-то идёт не так, а не для настройки поведения. Но если вы когда-либо смотрели на ошибку ERROR: tuple concurrently updated или cache lookup failed for relation NNNNN и задавались вопросом «откуда это в исходном коде», это инструмент для вас.
Первый исторический артефакт в кластере параметров на букву B. backslash_quote управляет тем, принимается ли \' как способ представления одиночной кавычки внутри строкового литерала SQL. Он существует из-за уязвимости SQL-инъекции 2006 года, связанной с многобайтовыми кодировками символов, и почти двадцать лет спустя он всё ещё находится в списке GUC, потому что его удаление нарушило бы работу какого-нибудь приложения где-то. PostgreSQL консервативен в таких вопросах.
Каждый кортеж кучи (heap tuple) живёт внутри страницы размером строго 8 КБ. Всё остальное построено поверх этого жёсткого ограничения: MVCC, HOT update и индексы, указывающие на (страница, указатель_строки). И тем не менее, это всё ещё работает:
CREATE TABLE docs (id int PRIMARY KEY, body jsonb);
INSERT INTO docs VALUES (1, (SELECT jsonb_agg(g) FROM generate_series(1, 100000) g));
Это значение body где-то за полмегабайта. Страница кучи по-прежнему имеет размер 8 КБ. Оба утверждения истинны одновременно, и механизм, который позволяет им сосуществовать, называется TOAST: The Oversized-Attribute Storage Technique (техника хранения чрезмерно больших атрибутов).
Прозрачное шифрование данных (Transparent Data Encryption, TDE) стало обязательным требованием для многих предприятий, хранящих конфиденциальные данные, будь то персональные или финансовые. Однако этот эффект обычно означает, что резервные копии бесполезны без отдельного хранимого ключа шифрования, а запуск самого сервера может не выполняться в полностью автоматизированном режиме (в зависимости от того, как настроено управление ключами). Взаимодействие между этими компонентами не всегда интуитивно понятно. Данная статья призвана внести ясность.
Этот документ по планированию содержит базовое введение или обзор как высокой доступности, так и прозрачного шифрования данных, а затем даёт обзор операционных проблем, связанных с совместным использованием этих двух технологий. Рекомендации касаются как инфраструктуры, которую следует учитывать, так и процессов, которые необходимо документировать, тестировать и отрабатывать.
Мы открываем кластер параметров на букву B параметром, само существование которого является признанием сложных отношений. У PostgreSQL сложные отношения с кэшем страниц Linux (page cache), и backend_flush_after — один из четырёх GUC, которые существуют для управления этими отношениями. Остальные три — bgwriter_flush_after, checkpoint_flush_after и wal_writer_flush_after — получат свои собственные статьи в своё время. Они используют общий механизм и имеют общую мотивацию, и эту мотивацию стоит понять, прежде чем мы погрузимся в конкретный параметр.
Последняя запись в кластере параметров автовакуума и самая новая. PostgreSQL 18 представил autovacuum_worker_slots для решения давней операционной проблемы: изменение autovacuum_max_workers ранее требовало перезапуска сервера, что делало невозможным реагирование на меняющуюся рабочую нагрузку вакуума без окна обслуживания. PG 18 исправляет это, разделяя параметр на две части.
С тех пор как в PostgreSQL существует логическая репликация, правило было таковым: если вы когда-нибудь захотите её использовать, установите wal_level = logical при запуске сервера и живите с объёмом WAL вечно. Стоимость не была катастрофической, но она была постоянной. Установите один раз — платите всегда, включая 364 дня в году, когда вы не использовали ни одного логического слота.
PostgreSQL 19 меняет это. Параметр всё ещё существует. Он просто больше не совсем то, что вы установили.
autovacuum_work_mem задаёт максимальный объём памяти, который каждый рабочий процесс автовакуума может использовать для отслеживания идентификаторов мёртвых кортежей (TID — tuple identifier) во время вакуума. Значение по умолчанию: -1, что означает «унаследовать от maintenance_work_mem». Контекст параметра — sighup. Этот параметр существует для того, чтобы потребление памяти автовакуумом можно было настраивать независимо от памяти, используемой ручным VACUUM, CREATE INDEX, REINDEX и другими разовыми операциями обслуживания.
За последний год я работал в нескольких контекстах, управляя большими объёмами данных, хранящихся в формате JSONB в PostgreSQL. Сценарий обычен: пользователи ценят гибкость документо-ориентированной модели хранения, избегая необходимости предопределять схемы или постоянно мигрировать структуры таблиц по мере изменения их требований к данным. JSONB-документы могут быть глубоко вложенными с многочисленными необязательными полями и масштабироваться до сотен килобайт на запись без проблем. Однако, когда приходит время запрашивать эти документы — фильтровать по идентификатору пользователя, типу события, временным меткам или вложенным свойствам действий — запросы могут стать медленными и/или неудобными для работы.
Проблема, которую я хочу решить: «Как сделать поиск по JSONB-данным более эффективным, не разбивая наши документы и не вставляя их в столбцы реляционной базы данных?» В Postgres доступно несколько подходов, каждый со своими компромиссами. Я надеюсь пролить свет на эти подходы в этой статье.
Классическая пара параметров запуска вакуума, наконец. Последние несколько статей мы потратили на параметры, которые изменяют, ограничивают или дополняют формулу запуска, управляемую этими двумя; теперь мы добрались до оригиналов.
Когда количество устаревших кортежей (обновлённых или удалённых строк) с момента последнего вакуума превышает это значение, автовакуум планирует выполнение VACUUM для таблицы. В PostgreSQL 18 и новее результат также ограничивается параметром autovacuum_vacuum_max_threshold. Значения по умолчанию: autovacuum_vacuum_threshold = 50, autovacuum_vacuum_scale_factor = 0.2. Оба параметра имеют контекст sighup, и для каждого существуют переопределения на уровне таблицы через параметры хранения.
Новинка в PostgreSQL 18. Этот параметр является первоклассным исправлением проблемы, с которой всё сообщество боролось около пятнадцати лет: на очень больших таблицах стандартная формула запуска вакуума ждёт абсурдно долго, прежде чем что-либо сделать.
При значениях по умолчанию — autovacuum_vacuum_threshold = 50 и autovacuum_vacuum_scale_factor = 0.2 — таблица на 100 миллионов строк ждёт 20 миллионов мёртвых кортежей, прежде чем запустится вакуум. Таблица на миллиард строк ждёт 200 миллионов. К моменту, когда вакуум действительно запускается, у вас уже огромное количество раздувания (bloat), сам вакуум занимает часы, а следующий запускается из такого же плохого состояния.
Классическим обходным решением (workaround) была покадровая настройка autovacuum_vacuum_scale_factor для каждой таблицы до значений вроде 0.02 или 0.005, которую мы обсудим, когда доберёмся до этих параметров в следующей статье. Это работает, но требует предварительного выявления каждой большой таблицы и назначения ей индивидуальных параметров хранения (storage parameters). Легко забыть, легко упустить, когда маленькая таблица вырастает в большую.
Эти два параметра образуют третью согласованную пару в комплекте автовакуума, после пары для ANALYZE и пары для обычного вакуума (последняя будет рассмотрена следующей). Они управляют тем, когда автовакуум запускает VACUUM для таблицы на основе количества вставок (INSERT) с момента последнего вакуума — не обновлений, не удалений, только вставок. Они были добавлены в PostgreSQL 13 и существуют для решения конкретной проблемы.
