SQL-Ex blog

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

ignore_system_indexes завершает череду из трёх последовательных параметров с именем ignore_-что-то и с удобным отрывом является самым вежливым в этом семействе. ignore_checksum_failure и ignore_invalid_pages говорят PostgreSQL продолжать, несмотря на доказательства повреждения; этот же просто говорит ему перестать доверять набору путей доступа. Это логический параметр, по умолчанию выключен, и он живёт в редком контексте backend: его можно установить только до того, как сессия существует, либо в postgresql.conf (влияя только на новые сессии), либо во время подключения, что удобнее всего сделать как PGOPTIONS="-P", эквивалентный серверный переключатель. Установите его после подключения — и получите ошибку. Во всех поддерживаемых версиях это один из ровно двух параметров с таким контекстом (другой — post_auth_delay), он классифицирован как параметр разработчика и не появляется в образце файла конфигурации. Всё это — способ сервера сказать: вы не должны были это находить.

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

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

Топик		Сообщений	Просмотров
 53 (SELECT)		7		6
 55 (Learn)		2		5

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

Рейтинг	 Участник (решенные задачи, время в днях)
 140		Rujan (143, 453.871)
 316		saah (109, 48.785)

Продолжить чтение "Новости за 2026-09-19 - 2026-09-25"

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

Никто не находит ignore_invalid_pages, читая документацию от корки до корки. Вы находите его, вставив PANIC: WAL contains references to invalid pages в поисковую систему, обычно в час, когда вы предпочли бы спать. Это параметр разработчика, отсутствующий в postgresql.conf.sample, присутствующий начиная с PostgreSQL 13. По умолчанию он выключен, а контекст — postmaster, что на этот раз ничего не стоит: сервер, который вам нужно было бы перезапустить, уже не работает.

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

Пересказ статьи Lee Asher. First Normal Form (1NF): Breaking the ‘unbreakable rule’ in database design

Первая нормальная форма (1NF) является самым известным правилом в нормализации базы данных. Оно требует, чтобы таблицы не содержали повторяющихся групп и каждый столбец содержал атомарные значения. Но в реальных системах баз данных разработчики часто намеренно нарушают это правило при моделировании сложных данных. Давайте выясним почему.

Правильная нормализация данных является критической проблемой при проектировании базы данных, контролируемой набором правил моделирования данных, известных как "нормальные формы". Хотя даже лучшие разработчики затрудняются в объяснении различия между более высокими нормальными формами, одно правило, которое мы все знаем, это Первая Нормальная Форма. Обычно ее называют 1НФ, а правило часто выражают просто тремя словами: нет повторяющихся групп.
Продолжить чтение "Первая нормальная форма (1NF): нарушение "ненарушаемого правила" в проектировании базы данных"

Christophe Pettus: All Your GUCs in a Row: ignore_checksum_failure

ignore_checksum_failure — это не столько параметр конфигурации, сколько ломик в витрине за стеклом. По умолчанию он выключен, он вообще не появляется в postgresql.conf.sample (образец файла вежливо отказывается его рекламировать), и документация помещает его в раздел «Параметры разработчика», рядом с другими инструментами, которые вы надеетесь никогда не будете держать в руках. Контекст — суперпользователь, что означает, что суперпользователь (или роль, которой было предоставлено право SET на него, а такой роли не должно существовать) может переключить его в живой сессии командой SET; без перезагрузки, без перезапуска. Именно такая гранулярность и требуется для его единственного законного применения. Он появился в PostgreSQL 9.3 вместе с самими контрольными суммами данных: функция, которая проверяет, и рычаг, который отменяет проверку, родились вместе.

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

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

idle_session_timeout — это уборка, а не защита. Его «собрат», idle_in_transaction_session_timeout, защищает базу данных от реального вреда: простаивающая транзакция удерживает блокировки и фиксирует горизонт xmin, и vacuum от этого страдает. Сессия, простаивающая вне транзакции, ничего из этого не делает. Она занимает слот соединения, фоновый процесс и немного памяти. Вот и весь счёт, и этот параметр существует, чтобы его выставить. В документации сказано то же самое, отмечая, что простаивающая сессия без транзакции не создаёт больших затрат, поэтому необходимости в этом таймауте меньше, чем в его «собрате».

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

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

idle_replication_slot_timeout делит алфавитное соседство с idle_in_transaction_session_timeout и idle_session_timeout, но решает противоположную проблему. Те отключают клиентов, которые остаются слишком долго. Этот же, новый в PostgreSQL 18, имеет дело с клиентами, которые вообще перестают появляться: он ставит срок годности на слоты репликации.

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

Пересказ статьи gbargsley. Beyond VARBINARY: How to Store PDFs in SQL Server Using FILESTREAM and FileTable

Сегодня мы поговорим о теме, которая возникает чаще, чем вы думаете: хранение PDF-документов внутри SQL Server.

Будут ли это счета, отчеты, отсканированные формы или контракты, приложениям часто нужно где-то хранить файлы. Вы могли бы хранить их в общей сетевой папке и надеяться, что ничто не повредит ссылку, или вы можете полностью перенести их в SQL Server, где они будут находиться вместе с вашими данными. В этой статье я собираюсь рассказать вам о настройке FILESTREAM и FileTable в SQL Server, средствах, которые дают вам лучшее из двух миров: транзакционная целостность от SQL Server и производительность файловой системы от NTFS. Продолжить чтение "За пределами VARBINARY: как сохранить PDF в SQL Server, используя FILESTREAM и FileTable"

§ Выполнена следующая цепочка переносов:
53 -> 11 -> 3 -> обучающий (167).
Второй этап начинается теперь с задачи №3.
Под номером 53 опубликована новая задача от pegoopik (сложность 3 балла).
Актуализируйте свой сертификат!

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

Топик		Сообщений	Просмотров
 54 (Learn)		3		6
 58 (Learn)		2		7
 Guest's book		2		8

§ Авторы недели на форуме

Автор		Сообщений
 Nividimka	2
 selber  	2
 gennadi_s  	2

Продолжить чтение "Новости за 2026-09-12 - 2026-09-18"

Alexey Evlampiev: Your Transaction Boundary Belongs in the Program, Not the Filename

Поэтапное изменение схемы охватывает транзакционную и нетранзакционную работу. Большинство фреймворков миграций выражают это различие как метаданные, другие делает его частью SQL-программы.

Продолжить чтение "Граница вашей транзакции принадлежит программе, а не имени файла"

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

idle_in_transaction_session_timeout существует потому, что на код приложения нельзя положиться в том, что он доведёт до конца то, что начал. ORM открывает транзакцию, исключение уводит выполнение по неожиданному пути, соединение возвращается в пул с всё ещё открытой транзакцией, и теперь у PostgreSQL есть сессия, которая будет удерживать всё, к чему прикоснулась, пока кто-нибудь это не заметит. Этот параметр и есть тот самый «кто-нибудь».

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

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

ident_file сообщает серверу, где находится pg_ident.conf. Вот и вся функция. Интересная часть — это то, что происходит, когда он указан неправильно, а именно: ничего, громко, в журнале, который никто не читает.

Значение по умолчанию — pg_ident.conf в каталоге конфигурации, то есть в каталоге, содержащем postgresql.conf, а не обязательно в каталоге данных. Контекст — postmaster, поэтому для изменения требуется перезапуск, и он несёт флаг «только для суперпользователя», поэтому непривилегированная роль, запрашивающая SHOW ident_file, получает ошибку прав доступа вместо ответа. Относительный путь разрешается относительно рабочего каталога того, кто запустил postgres, а не относительно PGDATA.

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

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

hot_standby_feedback не устраняет проблему. Он перемещает её — с резервного сервера на первичный, и вопрос о том, является ли это хорошим обменом, — это и есть весь вопрос.

Проблема заключается в конфликтах восстановления, которые отменяют долго выполняющиеся запросы на резервном сервере. Резервный сервер воспроизводит изменения первичного, одновременно отвечая на читающие запросы, и когда первичный очищает vacuum мёртвые версии строк, воспроизведение этой очистки на резервном сервере сталкивается с любым запросом, который всё ещё полагается на эти версии. Резервный сервер разрешает столкновение, убивая запрос, и пользователь видит ERROR: canceling statement due to conflict with recovery. hot_standby_feedback останавливает это, прося первичный сервер вообще не удалять эти строки. Стоимость ложится на первичный сервер в виде раздувания, потому что строки, которые он иначе освободил бы, теперь удерживаются запросом, выполняющимся на другой машине.

Именно поэтому он выключен по умолчанию. Значение по умолчанию подразумевает, что запросы резервного сервера не должны иметь возможности «дотянуться» и ограничивать обслуживание первичного. Его включение — это сознательное решение позволить им это.

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

Автор Alexey Evlampiev: Your ALTER TABLE Is Fast. The Queue Behind It Is Not

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

Вот один и тот же оператор, выполненный дважды для одной и той же таблицы — PostgreSQL 16.14 в локальном контейнере, таблица orders на 100 000 строк, конкурирующая сессия удерживается открытой через pg_sleep. Это иллюстративные числа с одной машины, а не бенчмарк; важен сам ratio, и вы можете воспроизвести его примерно за минуту.

-- Без конкуренции:

ALTER TABLE orders ADD COLUMN note text;

Time: 5.786 ms



-- С одним обычным долго выполняющимся SELECT, открытым на таблице:

ALTER TABLE orders ADD COLUMN note text;

Time: 18065.050 ms (00:18.065)

Второй запуск медленный не потому, что работа тяжелее. Работа идентична и занимает около шести миллисекунд в обоих случаях — добавление столбца без значения по умолчанию не касается ни одной строки, оно лишь редактирует каталог. Восемнадцать секунд тратятся на ожидание блокировки, и пока этот оператор ждёт, он делает кое-что похуже, чем просто медленно работает: он останавливает несвязанных читателей, которые иначе выполнились бы мгновенно.

Именно это стоит усвоить, и это верно независимо от того, какой инструмент миграции вы используете. Время выполнения без конкуренции говорит вам, сколько стоит оператор, когда ничто не стоит у него на пути; оно не предсказывает, во что он обойдётся вашим пользователям. Режим блокировки, время, проведённое в ожидании, и длина окружающей транзакции дополняют эту картину — и только первое число появляется в таймингах ваших миграций.

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

Продолжить чтение "ALTER TABLE выполняется быстро. Очередь за ним — нет"

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

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

Это логический параметр, по умолчанию включён, его контекст — postmaster, поэтому он фиксируется при запуске сервера. Он включает возможность подключаться к серверу, находящемуся в режиме восстановления, воспроизводящему WAL из архива или от потокового первичного сервера, и выполнять против него запросы только для чтения, пока это воспроизведение продолжается. Часть «только для чтения» обеспечивается принудительно, а не на доверии: любая сессия, подключённая во время восстановления, принудительно переводит свои транзакции в режим только для чтения, что бы клиент ни запрашивал. Функция, которую он включает, — Hot Standby — появилась в PostgreSQL 9.0 и отличает современную читающую реплику от более старого «тёплого резерва» (warm standby), который мог только сидеть и воспроизводить WAL до момента повышения.

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