Каждое соединение, которое кто-либо устанавливал с сервером PostgreSQL начиная с версии 8.0, открывалось с того, что сервер без приглашения объявлял значение integer_datetimes. Начиная с PostgreSQL 10 объявляемое значение — это единственное значение, с которым вообще может быть собран сервер PostgreSQL, и текущая документация отделывается от всей темы одним предложением: «Начиная с PostgreSQL 10 это всегда on». Так что это пост о том, почему параметр ровно с одним возможным значением всё ещё представляется каждому клиенту в начале каждого разговора.
in_hot_standby — это лампочка, а не переключатель. Он сообщает, является ли сервер, к которому вы подключены, в данный момент горячим резервом: включён, когда ваша сессия работает на реплике, которая воспроизводит WAL и принимает запросы только для чтения (состояние, которое включает hot_standby), выключен на первичном сервере. Это логический параметр, он появился в PostgreSQL 14, и его контекст — ни один из обычных четырёх, потому что никто не может его изменить:
postgres=# SET in_hot_standby = off;
ERROR: parameter "in_hot_standby" cannot be changed
postgres=# ALTER SYSTEM SET in_hot_standby = off;
ERROR: parameter "in_hot_standby" cannot be changed
ignore_system_indexes завершает череду из трёх последовательных параметров с именем ignore_-что-то и с удобным отрывом является самым вежливым в этом семействе. ignore_checksum_failure и ignore_invalid_pages говорят PostgreSQL продолжать, несмотря на доказательства повреждения; этот же просто говорит ему перестать доверять набору путей доступа. Это логический параметр, по умолчанию выключен, и он живёт в редком контексте backend: его можно установить только до того, как сессия существует, либо в postgresql.conf (влияя только на новые сессии), либо во время подключения, что удобнее всего сделать как PGOPTIONS="-P", эквивалентный серверный переключатель. Установите его после подключения — и получите ошибку. Во всех поддерживаемых версиях это один из ровно двух параметров с таким контекстом (другой — post_auth_delay), он классифицирован как параметр разработчика и не появляется в образце файла конфигурации. Всё это — способ сервера сказать: вы не должны были это находить.
Никто не находит ignore_invalid_pages, читая документацию от корки до корки. Вы находите его, вставив PANIC: WAL contains references to invalid pages в поисковую систему, обычно в час, когда вы предпочли бы спать. Это параметр разработчика, отсутствующий в postgresql.conf.sample, присутствующий начиная с PostgreSQL 13. По умолчанию он выключен, а контекст — postmaster, что на этот раз ничего не стоит: сервер, который вам нужно было бы перезапустить, уже не работает.
Первая нормальная форма (1NF) является самым известным правилом в нормализации базы данных. Оно требует, чтобы таблицы не содержали повторяющихся групп и каждый столбец содержал атомарные значения. Но в реальных системах баз данных разработчики часто намеренно нарушают это правило при моделировании сложных данных. Давайте выясним почему.
ignore_checksum_failure — это не столько параметр конфигурации, сколько ломик в витрине за стеклом. По умолчанию он выключен, он вообще не появляется в postgresql.conf.sample (образец файла вежливо отказывается его рекламировать), и документация помещает его в раздел «Параметры разработчика», рядом с другими инструментами, которые вы надеетесь никогда не будете держать в руках. Контекст — суперпользователь, что означает, что суперпользователь (или роль, которой было предоставлено право SET на него, а такой роли не должно существовать) может переключить его в живой сессии командой SET; без перезагрузки, без перезапуска. Именно такая гранулярность и требуется для его единственного законного применения. Он появился в PostgreSQL 9.3 вместе с самими контрольными суммами данных: функция, которая проверяет, и рычаг, который отменяет проверку, родились вместе.
idle_session_timeout — это уборка, а не защита. Его «собрат», idle_in_transaction_session_timeout, защищает базу данных от реального вреда: простаивающая транзакция удерживает блокировки и фиксирует горизонт xmin, и vacuum от этого страдает. Сессия, простаивающая вне транзакции, ничего из этого не делает. Она занимает слот соединения, фоновый процесс и немного памяти. Вот и весь счёт, и этот параметр существует, чтобы его выставить. В документации сказано то же самое, отмечая, что простаивающая сессия без транзакции не создаёт больших затрат, поэтому необходимости в этом таймауте меньше, чем в его «собрате».
idle_replication_slot_timeout делит алфавитное соседство с idle_in_transaction_session_timeout и idle_session_timeout, но решает противоположную проблему. Те отключают клиентов, которые остаются слишком долго. Этот же, новый в PostgreSQL 18, имеет дело с клиентами, которые вообще перестают появляться: он ставит срок годности на слоты репликации.
Сегодня мы поговорим о теме, которая возникает чаще, чем вы думаете: хранение 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 балла).
Актуализируйте свой сертификат!
Поэтапное изменение схемы охватывает транзакционную и нетранзакционную работу. Большинство фреймворков миграций выражают это различие как метаданные, другие делает его частью SQL-программы.
idle_in_transaction_session_timeout существует потому, что на код приложения нельзя положиться в том, что он доведёт до конца то, что начал. ORM открывает транзакцию, исключение уводит выполнение по неожиданному пути, соединение возвращается в пул с всё ещё открытой транзакцией, и теперь у PostgreSQL есть сессия, которая будет удерживать всё, к чему прикоснулась, пока кто-нибудь это не заметит. Этот параметр и есть тот самый «кто-нибудь».
ident_file сообщает серверу, где находится pg_ident.conf. Вот и вся функция. Интересная часть — это то, что происходит, когда он указан неправильно, а именно: ничего, громко, в журнале, который никто не читает.
Значение по умолчанию — pg_ident.conf в каталоге конфигурации, то есть в каталоге, содержащем postgresql.conf, а не обязательно в каталоге данных. Контекст — postmaster, поэтому для изменения требуется перезапуск, и он несёт флаг «только для суперпользователя», поэтому непривилегированная роль, запрашивающая SHOW ident_file, получает ошибку прав доступа вместо ответа. Относительный путь разрешается относительно рабочего каталога того, кто запустил postgres, а не относительно PGDATA.
hot_standby_feedback не устраняет проблему. Он перемещает её — с резервного сервера на первичный, и вопрос о том, является ли это хорошим обменом, — это и есть весь вопрос.
Проблема заключается в конфликтах восстановления, которые отменяют долго выполняющиеся запросы на резервном сервере. Резервный сервер воспроизводит изменения первичного, одновременно отвечая на читающие запросы, и когда первичный очищает vacuum мёртвые версии строк, воспроизведение этой очистки на резервном сервере сталкивается с любым запросом, который всё ещё полагается на эти версии. Резервный сервер разрешает столкновение, убивая запрос, и пользователь видит ERROR: canceling statement due to conflict with recovery. hot_standby_feedback останавливает это, прося первичный сервер вообще не удалять эти строки. Стоимость ложится на первичный сервер в виде раздувания, потому что строки, которые он иначе освободил бы, теперь удерживаются запросом, выполняющимся на другой машине.
Именно поэтому он выключен по умолчанию. Значение по умолчанию подразумевает, что запросы резервного сервера не должны иметь возможности «дотянуться» и ограничивать обслуживание первичного. Его включение — это сознательное решение позволить им это.
