SQL-Ex blog

Автор: Payal Singh,Postgres War Stories Part 2: multixact wraparound, TOAST corruption, and torn pages

Три способа, которыми внутри Postgres портятся данные, не оставляя следов в журнале, и задачи, которые выявляют это раньше пользователей.

Первая часть была посвящена сбоям, которые начинаются на уровень ниже Postgres: ядро, glibc, аллокатор страниц. Эта статья — о худшем классе, когда сбой происходит внутри самого Postgres. Журналы чисты. Восстановление никогда не запускается. И запрос либо возвращает неверный ответ, либо «роняет» строки, которые всё ещё лежат на диске.

Три инцидента ниже не имеют ничего общего, кроме того, что делает их опасными: нет ошибки, на которую можно было бы настроить оповещение. Переполнение счётчика multixact, отсутствующий фрагмент TOAST, оборванная страница на диске — ничто из этого не подаёт сигнала. База данных не знает, что она неверна. Вы либо планируете задачу, которая будет это искать, либо узнаёте об этом, когда пользователь сообщает, что строки, которую он клянётся, что она была, больше нет.

Так что эта статья — наполовину про инциденты, наполовину про обнаружение. Обнаружение — вот в чём суть.

Продолжить чтение "Истории про отказ multixact из-за циклического переполнения, повреждение TOAST и оборванные страницы"

Автор: Christophe Pettus, All Your GUCs in a Row: effective_io_concurrency

Большинство параметров, меняющихся между версиями, меняют своё значение по умолчанию. effective_io_concurrency — более редкий случай: он дважды менял своё значение, и то, чем он управляет в PostgreSQL 18, отличается от того, чем он управлял в 17, что в свою очередь отличалось от того, что он означал до 13. Значение, скопированное вами из руководства по настройке 2019 года в современный кластер, не просто устарело — оно может отвечать на вопрос, который PostgreSQL больше не задаёт. Поэтому этот параметр лучше всего объяснять в виде истории. Текущее состояние, чтобы задать точку отсчёта: значение по умолчанию — 16, контекст — user, диапазон от 0 до 1000, где 0 отключает функцию.

Продолжить чтение "Всё о GUC по порядку: effective_io_concurrency"

Автор: Robins Tharakan,Why Postgres Doesn't Have synchronous_commit=remote_receive?

В распределённых средах баз данных баланс между долговечностью и производительностью — это постоянная борьба. Параметр synchronous_commit в PostgreSQL находится в центре этого вопроса, давая администраторам возможность выбирать, когда именно команда COMMIT возвращает успех клиенту.

Идея remote_receive родилась из простого вопроса: даёт ли пропуск записи на диск на резервном сервере измеримый, реальный прирост производительности? Ожидая только получения байтов WAL в памяти резервного сервера, можно ли получить значительное улучшение по сравнению с remote_write? Я взялся реализовать и протестировать эту возможность, чтобы выяснить это.

За этим последовало путешествие по задержкам сети, кэшу страниц ОС, «перегрузке» планировщика ЦП и шуму при бенчмаркинге. Вот подробности реализации, тестов, первоначальных аномалий и итоговых результатов.

Продолжить чтение "Почему в Postgres нет synchronous_commit=remote_receive?"

Автор: Christophe Pettus, All Your GUCs in a Row: effective_cache_size

Это один из наиболее последовательно неправильно понимаемых параметров PostgreSQL, и непонимание всегда имеет одну и ту же форму: люди верят, что effective_cache_size что-то делает с памятью. Он выделяет кэш. Он резервирует оперативную память. Он управляет тем, сколько PostgreSQL держит в памяти. Он не делает ничего из этого. Он не выделяет ничего, не резервирует ничего и вообще не меняет поведение во время выполнения. Это всего лишь одно число, переданное планировщику запросов, и его единственный эффект — изменять то, какие планы планировщик считает дешёвыми. Значение по умолчанию — 4 ГБ, контекст — user, и он заслуживает большего, чем обычное количество слов, потому что ошибиться с ним так легко и это так тихо и дорого обходится.

Продолжить чтение "Всё о GUC по порядку: effective_cache_size"

§ Автор усилил проверку задачи 241 (SELECT, рейтинг) и поднял ее сложность до 2 баллов.

§ Под номером 242 опубликована новая задачи от gennadi_s (SELECT, рейтинг, сложность 2 балла).

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 241 (SELECT)		11		4
 Guest's book		3		8
 134 (SELECT)		2		4

Продолжить чтение "Новости за 2026-07-11 - 2026-07-17"

Автор: Christophe Pettus, All Your GUCs in a Row: dynamic_shared_memory_type

dynamic_shared_memory_type выбирает механизм операционной системы, который PostgreSQL использует для динамической разделяемой памяти — памяти, выделяемой после запуска, в отличие от фиксированной области shared_buffers, которая выделяется один раз при загрузке. Контекст — postmaster, поэтому для изменения требуется перезапуск, а значение по умолчанию выбирается initdb в зависимости от поддержки вашей платформы: posix в Linux и большинстве Unix, windows в Windows. Вероятно, вы никогда не будете устанавливать его намеренно. Однако вы можете столкнуться с проблемой в контейнере, и это часть, заслуживающая вашего внимания.

Продолжить чтение "Всё о GUC по порядку: dynamic_shared_memory_type"

Автор: Christophe Pettus, All Your GUCs in a Row: dynamic_library_path

dynamic_library_path указывает PostgreSQL, где искать загружаемый C-модуль, когда что-то — CREATE FUNCTION ... LANGUAGE C, команда LOAD, запись в shared_preload_libraries — указывает библиотеку по простому имени файла без пути. Значение по умолчанию — $libdir, контекст — superuser, и большую часть своей жизни этот параметр был тем, к чему никто не прикасался. PostgreSQL 18 дал ему повод снова стать важным, и к этому мы в итоге и придём.

Продолжить чтение "Всё о GUC по порядку: dynamic_library_path"

Пересказ статьи Paul Ramsey. Postgres JSONB Columns and TOAST: A Performance Guide

PostgreSQL имеет большой набор функций, ориентированных на пользователя, которые работают в самых разных случаях использования — со сложной абстракцией под капотом.

Работа с API и массивами с типом данных jsonb становится все более популярной в настоящее время, и хранение фрагментов данных приложения с использованием jsonb становится общим шаблоном проектирования.

Но зачем разбивать объект JSON на строки и столбцы, а затем восстанавливать его позже, чтобы отправить обратно клиенту?

Ответом является эффективность. PostgreSQL наиболее эффективен при работе со строками и столбцами, и сокрытие структуры данных внутри JSON не позволяет движку работать так быстро, как он мог бы.
Продолжить чтение "Столбцы JSONB и TOAST в Postgres: пособие по производительности"

Автор: Christophe Pettus, All Your GUCs in a Row: default_transaction_deferrable

Оставшиеся два из трёх параметров default_transaction_*, завершающие набор, начатый параметром default_transaction_deferrable. Каждый из них устанавливает значение по умолчанию для сеанса для одного из трёх свойств транзакции — уровня изоляции, режима доступа и отложенности, — и для всех трёх правило одинаково: область действия GUC редко является той, которая вам нужна. Интересное содержание заключается в том, что означают значения, и для уровня изоляции это больше, чем думает большинство людей.

Продолжить чтение "Всё о GUC по порядку: default_transaction_isolation and default_transaction_read_only"

Автор: Richard Yen, Disaster Recovery is a Process, Not a Tool (Part 1)

Когда я работал в Turnitin, мы всё ещё находились на спаде бума доткомов. Все спешили выпускать продукты, и кратковременные сбои, конечно, были нежелательны, но считались нормальной частью работы программного обеспечения в интернете. Если сайт был недоступен несколько минут, вы пожимали плечами, разбирались и исправляли.

Ландшафт изменился

Это уже не тот мир, в котором мы живём сейчас. Время безотказной работы стало гораздо более критичным, чем раньше. Пять девяток когда-то были амбициозной целью — теперь четыре девятки для многих команд являются просто ожидаемым стандартом, и даже несколько минут простоя в месяц кажутся большой проблемой. Мы больше не отслеживаем средние значения в наших метриках; мы отслеживаем p99-задержки, потому что нам действительно важно, чтобы последний 1% пользователей получал хороший опыт работы.

Ещё одна вещь, которая изменилась, — это скорость, с которой сбои становятся достоянием общественности. Заметный сбой в вашем сервисе может попасть в социальные сети ещё до того, как ваш дежурный успеет подтвердить получение оповещения. По моему опыту, самые плохие ситуации — это те, когда клиенты узнают о проблеме раньше, чем компания. Это имеет как финансовые, так и репутационные издержки, причём репутационные издержки имеют свойство сохраняться ещё долго после устранения инцидента. Частые сбои подрывают желание пользователей продолжать использовать ваш продукт.

Postgres, конечно, не исключение. Именно в таком мире и должен действовать план аварийного восстановления Postgres.

Продолжить чтение "Аварийное восстановление — это процесс, а не инструмент (Часть 1)"

Автор: Christophe Pettus, All Your GUCs in a Row: default_transaction_deferrable

default_transaction_deferrable устанавливает значение по умолчанию для атрибута транзакции DEFERRABLE для новых транзакций. Значение по умолчанию — off, контекст — user, и атрибут, который он задаёт по умолчанию, не делает ничего, если только не выполнены два других условия, — именно поэтому этот параметр заслуживает нескольких сотен слов, а не одного предложения.

Продолжить чтение "Всё о GUC по порядку: default_transaction_deferrable"

Автор: Christophe Pettus, All Your GUCs in a Row: default_toast_compression

default_toast_compression определяет, какой алгоритм PostgreSQL использует для сжатия значений, направляемых в TOAST — внестрочное хранилище для значений полей, слишком больших, чтобы помещаться непосредственно на странице кучи размером 8 КБ. Доступны варианты pglz и lz4; по умолчанию во всех выпущенных на данный момент версиях используется pglz; контекст — user, и его можно переопределить для каждого столбца с помощью опции COMPRESSION в CREATE TABLE или ALTER TABLE. Параметр существует начиная с PostgreSQL 14, и более интересный факт заключается в том, что его значение по умолчанию, наконец, скоро изменится.

Продолжить чтение "Всё о GUC по порядку: default_toast_compression"

Автор: Christophe Pettus, All Your GUCs in a Row: default_text_search_config

default_text_search_config определяет конфигурацию полнотекстового поиска, которую используют функции PostgreSQL для полнотекстового поиска, если вы явно не передаёте им конфигурацию. Значение по умолчанию устанавливается командой initdb на основе локали кластера; контекст — user. Конфигурация полнотекстового поиска связывает парсер (который разбивает текст на токены) с цепочкой словарей (которые преобразуют токены в лексемы — например, приводят «бегущий» к «бежать», отбрасывают стоп-слова вроде «и»), и каждый вызов to_tsvector и to_tsquery нуждается в конфигурации для своей работы. Этот параметр используется теми вызовами, которые опускают явное указание конфигурации.

Это звучит как удобство, и в основном так оно и есть, но этот параметр основан на одном из самых элегантных ограничений PostgreSQL, и именно это ограничение и есть суть данной статьи.

Продолжить чтение "Всё о GUC по порядку: default_text_search_config"

Автор: Christophe Pettus, All Your GUCs in a Row: default_tablespace

Сначала о механике, поскольку она кратка: когда default_tablespace содержит что-либо, кроме пустой строки, он неявно добавляет предложение TABLESPACE к каждой команде CREATE TABLE и CREATE INDEX, в которой это предложение явно не указано, включая индекс, создаваемый для ограничений UNIQUE или PRIMARY KEY. Значение по умолчанию — пустая строка, что означает «использовать табличное пространство самой базы данных», а контекст — user. Чтобы иметь мнение об этом параметре, нужно иметь мнение о табличных пространствах, и моё, в 2026 году, таково: в основном не используйте. Мы ещё дойдём до этого. Сначала — особенности.

Продолжить чтение "Всё о GUC по порядку: default_tablespace"

§ Лидеры недели

	Участник		w_sel	all_sel	select	dml	Всего	Рейтинг
 Багманов Д.Д.  (Bagmanov_Dinar	20	20	28	11	39	2643
 Шибаев  (saah)                	7	57	18	0	18	1234
 Сафронов П.А.  (Paulus73)     	5	155	14	0	14	134
 Odnokurtsev  (AlFochino)      	3	127	8	59	67	175
 Fom  (Kamchatka)              	3	9	5	0	5	5634
 Smirnov S. (hr)               	3	28	4	0	4	1388

§ Претенденты на попадание в TOP 100

Рейтинг	 Участник (решенные задачи, время в днях)
 134		Paulus73 (155, 15.028)
 140		Rujan (143, 451.925)
 169		Tigra1 (138, 24.441)
 175		AlFochino (127, 121.400)

Продолжить чтение "Новости за 2026-07-04 - 2026-07-10"