Новости за 2026-06-06 - 2026-06-12
§ Задача 303 перенесена на третий этап под номером 241.
§ Популярные темы недели на форуме
Топик Сообщений ПросмотровContinue reading "Новости за 2026-06-06 - 2026-06-12"
Guest's book 4 11
241 (SELECT) 3 4
§ Задача 303 перенесена на третий этап под номером 241.
§ Популярные темы недели на форуме
Топик Сообщений ПросмотровContinue reading "Новости за 2026-06-06 - 2026-06-12"
Guest's book 4 11
241 (SELECT) 3 4
Автор: Christophe Pettus, All Your GUCs in a Row: the debug_* family
Двенадцать параметров имеют префикс debug_, и этот префикс является значимым: это собственные средства разработки и контроля качества PostgreSQL, предоставленные в виде настроек времени выполнения, чтобы сборочная ферма (buildfarm) и разработчики ядра могли тестировать пути кода без перекомпиляции. Pavlo Golub, пишущий об одном из них, подвёл итог правильному подходу: «Я никогда-никогда не буду трогать параметр времени выполнения с префиксом “debug” в своих производственных кластерах». В основном это правильно. Давайте разберём дюжину параметров и то, что они на самом деле дают, потому что один или два тихо полезны, а остальными стоит восхищаться с безопасного расстояния.
Пересказ статьи Louis Davidson. The evil (and value) of DISTINCT
Автор: Christophe Pettus, All Your GUCs in a Row: bgwriter_delay and bgwriter_flush_after
Кластер параметров на букву B меняет направление: от разовых странностей к параметрам фонового процесса записи (background writer), которых насчитывается четыре GUC. Первые два мы рассмотрим как пару, потому что bgwriter_delay знакомит нас с самим процессом, а bgwriter_flush_after органично вписывается в экскурсию по механизму writeback из статьи про backend_flush_after.
Пересказ статьи Lukas Vileikis. MySQL Index Overviews FULLTEXT B-Tree Indexes
Автор: Christophe Pettus, All Your GUCs in a Row: backtrace_functions
Параметр для разработчиков (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 и задавались вопросом «откуда это в исходном коде», это инструмент для вас.
§ Популярные темы недели на форуме
Топик Сообщений Просмотров
231 (SELECT) 6 3
147 (SELECT) 5 6
41 (Learn) 3 9
234 (SELECT) 3 5
40 (Learn) 2 10
§ Авторы недели на форуме
Автор Сообщений
pegoopik 10
alex_v 6
selber 4
SqlExOYMaxim 3
Автор: Christophe Pettus, All Your GUCs in a Row: backslash_quote
Первый исторический артефакт в кластере параметров на букву B. backslash_quote управляет тем, принимается ли \' как способ представления одиночной кавычки внутри строкового литерала SQL. Он существует из-за уязвимости SQL-инъекции 2006 года, связанной с многобайтовыми кодировками символов, и почти двадцать лет спустя он всё ещё находится в списке GUC, потому что его удаление нарушило бы работу какого-нибудь приложения где-то. PostgreSQL консервативен в таких вопросах.
Автор: Radim Marek, TOAST: Where PostgreSQL hides big values
Каждый кортеж кучи (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 (техника хранения чрезмерно больших атрибутов).
Автор: stormatics.tech, Transparent Data Encryption and High Availability
Прозрачное шифрование данных (Transparent Data Encryption, TDE) стало обязательным требованием для многих предприятий, хранящих конфиденциальные данные, будь то персональные или финансовые. Однако этот эффект обычно означает, что резервные копии бесполезны без отдельного хранимого ключа шифрования, а запуск самого сервера может не выполняться в полностью автоматизированном режиме (в зависимости от того, как настроено управление ключами). Взаимодействие между этими компонентами не всегда интуитивно понятно. Данная статья призвана внести ясность.
Этот документ по планированию содержит базовое введение или обзор как высокой доступности, так и прозрачного шифрования данных, а затем даёт обзор операционных проблем, связанных с совместным использованием этих двух технологий. Рекомендации касаются как инфраструктуры, которую следует учитывать, так и процессов, которые необходимо документировать, тестировать и отрабатывать.
Continue reading "Прозрачное шифрование данных и высокая доступность"Автор: Christophe Pettus, All Your GUCs in a Row: backend_flush_after
Мы открываем кластер параметров на букву B параметром, само существование которого является признанием сложных отношений. У PostgreSQL сложные отношения с кэшем страниц Linux (page cache), и backend_flush_after — один из четырёх GUC, которые существуют для управления этими отношениями. Остальные три — bgwriter_flush_after, checkpoint_flush_after и wal_writer_flush_after — получат свои собственные статьи в своё время. Они используют общий механизм и имеют общую мотивацию, и эту мотивацию стоит понять, прежде чем мы погрузимся в конкретный параметр.
Автор: Shridhar Khanal, SSL in PostgreSQL
Continue reading "SSL в PostgreSQL: введение в шифрование подключений к базе данных"
«"SSL включён" и "SSL действительно работает" — это две большие разницы».
Автор: Christophe Pettus, All Your GUCs in a Row: autovacuum_worker_slots
Последняя запись в кластере параметров автовакуума и самая новая. PostgreSQL 18 представил autovacuum_worker_slots для решения давней операционной проблемы: изменение autovacuum_max_workers ранее требовало перезапуска сервера, что делало невозможным реагирование на меняющуюся рабочую нагрузку вакуума без окна обслуживания. PG 18 исправляет это, разделяя параметр на две части.
Автор: Christophe Pettus, The wal_level You Set Is Not the wal_level You Get
С тех пор как в PostgreSQL существует логическая репликация, правило было таковым: если вы когда-нибудь захотите её использовать, установите wal_level = logical при запуске сервера и живите с объёмом WAL вечно. Стоимость не была катастрофической, но она была постоянной. Установите один раз — платите всегда, включая 364 дня в году, когда вы не использовали ни одного логического слота.
PostgreSQL 19 меняет это. Параметр всё ещё существует. Он просто больше не совсем то, что вы установили.
Continue reading "wal_level, который вы установили, — это не тот wal_level, который вы получите"Автор: Christophe Pettus, All Your GUCs in a Row: autovacuum_work_mem
autovacuum_work_mem задаёт максимальный объём памяти, который каждый рабочий процесс автовакуума может использовать для отслеживания идентификаторов мёртвых кортежей (TID — tuple identifier) во время вакуума. Значение по умолчанию: -1, что означает «унаследовать от maintenance_work_mem». Контекст параметра — sighup. Этот параметр существует для того, чтобы потребление памяти автовакуумом можно было настраивать независимо от памяти, используемой ручным VACUUM, CREATE INDEX, REINDEX и другими разовыми операциями обслуживания.