§ Популярные темы недели на форуме
Топик Сообщений Просмотров
53 (SELECT) 2 6
140 (SELECT) 2 5
209 (SELECT) 2 4
58 (Learn) 2 5
§ Лидеры недели
Участник w_sel all_sel select dml Всего РейтингПродолжить чтение "Новости за 2026-10-31 - 2026-11-06"
Gitinomagomedov (gmansur88) 11 99 25 0 25 269
Ш С. (junopark1) 8 76 18 0 18 422
Иванова О.Н. (olga_ivanova) 10 19 13 0 13 1667
O (janeoosql) 4 36 10 0 10 1262
Timonin D.E. (DmiTim) 3 70 5 0 5 531
Автор Christophe Pettus: All Your GUCs in a Row: max_replication_slots
max_replication_slots — это размер массива в общей памяти, и ничего больше. Этот параметр не определяет, кому разрешено создавать слоты, сколько WAL может удерживать слот и когда система должна очищать заброшенные слоты. Он задаёт количество элементов в массиве. Сам массив выделяется один раз при запуске сервера, поэтому единственная действительно важная особенность этого значения заключается в том, что изменить его без перезапуска невозможно.
Автор Gülçin Yıldırım Jelíenk: New system views in PostgreSQL 19
Работая над статьёй об улучшениях мониторинга в PostgreSQL 19 и готовя новый доклад о наблюдаемости PostgreSQL для конференции PostgreSQL Conference Europe, которая состоялась в октябре, я заметила, что в этом выпуске системным представлениям посвятили отдельный раздел. Последний раз им уделяли столь же заметное внимание в PostgreSQL 13 и 14. Поэтому я решила, что системные представления заслуживают отдельной статьи, в которой можно подробно разобрать все изменения.
Продолжить чтение "Новые системные представления в PostgreSQL 19"Подготовленная транзакция — это транзакция, отделённая от своего сеанса. После выполнения команды PREPARE TRANSACTION 'some-gid' сеанс, в котором она была начата, больше не содержит никакой активной транзакции. Однако выполненные изменения, установленные блокировки и идентификатор транзакции продолжают существовать самостоятельно: информация о них записана в WAL, состояние отслеживается в общей памяти, а после аварийного завершения работы сервера транзакция восстанавливается и ожидает, пока кто-нибудь не выполнит COMMIT PREPARED 'some-gid' или ROLLBACK PREPARED 'some-gid'.
Параметр max_prepared_transactions определяет, сколько таких транзакций, существующих отдельно от своих сеансов, сервер может одновременно удерживать. Значение по умолчанию — 0, верхняя граница — 262143. Контекст настройки — postmaster, поэтому для включения этой возможности потребуется перезапуск сервера. Для её отключения перезапуск тоже необходим.
Christophe Pettus: All Your GUCs in a Row: max_pred_locks_per_transaction
У параметра max_pred_locks_per_transaction есть та же проблема с названием, что и у max_locks_per_transaction, а вдобавок и собственная особенность. Как и его тезка, он определяет размер таблицы, рассчитанный на каждый слот серверного процесса, а не ограничивает количество блокировок отдельной транзакции. Но, в отличие от своего тезки, большая часть записей в этой таблице в любой момент времени относится к транзакциям, которые уже завершились фиксацией.
Автор Christophe Pettus: All Your GUCs in a Row: max_pred_locks_per_page and max_pred_locks_per_relation
При использовании уровня изоляции SERIALIZABLE PostgreSQL должен запоминать, какие данные прочитала каждая транзакция. Для этого выделен определённый объём общей памяти, и он ограничен.
Эти два параметра определяют, в какой момент сервер перестаёт отслеживать отдельные строки и начинает учитывать всю страницу целиком, а затем — когда перестаёт отслеживать отдельные страницы и начинает учитывать всю таблицу. Каждое такое снижение точности отслеживания оборачивается ошибками сериализации, которых при более точном учёте можно было бы избежать.
Продолжить чтение "Всё о GUC по порядку: max_pred_locks_per_page и max_pred_locks_per_relation"Автор Christophe Pettus: All Your GUCs in a Row: max_parallel_apply_workers_per_subscription
Название параметра обещает параллельное применение изменений, поэтому любой, кто наблюдает за отставанием подписчика от издателя, рано или поздно находит его и надеется, что он решит проблему. Но возможности параметра гораздо уже, чем можно предположить.
Продолжить чтение "Всё о GUC по порядку: max_parallel_apply_workers_per_subscription"Пересказ статьи Lee Asher. What is fillfactor in PostgreSQL – and when should you adjust it
Christophe Pettus: Workers of the World, Unite! – PostgreSQL Background Worker Configuration
PostgreSQL обзавёлся множеством фоновых рабочих процессов, в том числе предназначенных для выполнения различных операций параллельно. Сейчас их стало так много, что разобраться во всём этом уже непросто. Давайте наведём порядок.
Продолжить чтение "Рабочие процессы всех стран, объединяйтесь!"Автор Christophe Pettus: All Your GUCs in a Row: max_parallel_workers and max_parallel_workers_per_gather
Ни один из этих параметров не означает того, что можно предположить по его названию.
max_parallel_workers_per_gather задаёт максимальное количество рабочих процессов, которое планировщик может запросить для одного узла плана выполнения. Однако обычно планировщик запрашивает меньше.
Параметр max_parallel_workers в документации описывается как ограничение, действующее для всего кластера. Но фактически оно обеспечивается сравнением общего количества работающих процессов с числом, которое каждый отдельный сеанс устанавливает самостоятельно.
Автор Christophe Pettus: All Your GUCs in a Row: max_parallel_maintenance_workers
max_parallel_maintenance_workers — это верхнее ограничение, до которого в большинстве случаев просто не удаётся добраться: раньше срабатывает какое-нибудь другое ограничение. Параметр задаёт максимальное количество параллельных рабочих процессов, которые может запустить одна служебная команда. Значение по умолчанию — 2, контекст настройки — user, допустимый диапазон — от 0 до 1024. Значение 0 полностью отключает параллельное обслуживание. Увеличить значение параметра несложно. Гораздо труднее добиться того, чтобы команда действительно использовала выделенное ей количество процессов.
§ Популярные темы недели на форуме
Топик Сообщений Просмотров
192 (SELECT) 8 2
209 (SELECT) 3 2
56 (Learn) 2 6
82 (Learn) 2 6
§ Авторы недели на форуме
Автор СообщенийПродолжить чтение "Новости за 2026-10-24 - 2026-10-30"
pegoopik 6
gennadi_s 6
8bobrik8 3
Murderface_ 2
Christophe Pettus: All Your GUCs in a Row: max_logical_replication_workers
max_logical_replication_workers определяет размер пула процессов. В документации перечислены три типа рабочих процессов, использующих этот пул (в PostgreSQL 19 их уже четыре), и на этом объяснение заканчивается. Но упущено самое важное: из всех перечисленных типов только один учитывается при выборе значения параметра, хотя при исчерпании пула ничего не завершается ошибкой. Просто подписка так и не сможет завершить свою работу.
Christophe Pettus: All Your GUCs in a Row: max_notify_queue_pages
Параметр max_notify_queue_pages никому не был нужен. Он появился потому, что ограничение, которое раньше обеспечивалось само собой, перестало работать, и пришлось придумать ему замену.
Christophe Pettus: All Your GUCs in a Row: max_locks_per_transaction
max_locks_per_transaction — это ни «на транзакцию», ни «максимум». Это доля на процесс в одной общей для всего кластера таблице блокировок, и любая отдельная транзакция может взять гораздо больше своей доли, пока никто другой не использует свою. Имя вводит людей в заблуждение с 7.2, а описание в документации как «среднего числа объектных блокировок, используемых каждой транзакцией» ближе к истине, хотя вряд ли это то, что вы нанесёте на ручку настройки.