Ни один из этих параметров не имеет никакого отношения к методу аутентификации krb5, поскольку PostgreSQL удалил этот метод в версии 9.4. Приставка krb_ сохраняется по той обычной причине, по которой имена параметров переживают всё: переименование GUC ломает каждый postgresql.conf, который его упоминает. На самом деле они настраивают аутентификацию GSSAPI — метод gss в pg_hba.conf, который означает Kerberos, а на практике это обычно означает Active Directory (их «собратьям повезло меньше: krb_server_hostname ушёл в 8.4, а krb_srvname пошёл ко дну вместе с кораблём в 9.4).
Большая часть политики GSSAPI живёт в pg_hba.conf, построчно: include_realm, krb_realm, map. Эти две настройки являются общесерверными, поэтому они вообще являются GUC. Обе имеют контекст sighup; перезагрузки конфигурации достаточно, перезапуск не нужен.
«Отказоустойчивый PostgreSQL» обычно означает выборы лидера, потоковые реплики, автоматическое переключение при сбое, проверки работоспособности и массу тщательного связывания. С оператором CYBERTEC PG Operator (CPO) это означает YAML-файл из 14 строк. Вот он целиком, от начала до конца, на ноутбуке с minikube.
Каждая команда и каждый вывод ниже взяты из учебного руководства, которое мы выполнили от начала до конца на свежем minikube (Kubernetes 1.30, CPO 0.9.2, PostgreSQL 18.4).
PostgreSQL, как известно, не реализует подсказки к запросам. Это примерно на 95% правда, и join_collapse_limit — это те самые оставшиеся 5%: установите его в 1, и планировщик соединит ваши таблицы ровно в том порядке, в котором вы их написали. Это не эксплойт и не случайность реализации; это задокументировано, и, по словам Тома Лейна (Tom Lane) в списке pgsql-hackers, это по сути причина, по которой параметр всё ещё существует. Проект годами говорил людям, что они могут навязать порядок соединений, написав явное вложение JOIN, и удаление этого аварийного люка показалось плохой идеей. Так что у PostgreSQL есть ровно одна подсказка порядка соединений. Просто она не пишется как подсказка.
Семейство jit_* закрывается тремя параметрами для тех, кто работает над самим JIT, а не с ним. Все три — логические, все по умолчанию выключены, все восходят к исходной работе над PostgreSQL 11 и все живут в разделе «Параметры разработчика». Что делает их достойными поста, так это то, что один из них действительно интересен, а два других демонстрируют контекст GUC, которого эта серия ещё не встречала.
Третий блок семейства jit_* — тот, который решает, когда JIT срабатывает, и именно здесь живут неприятности. Все три появились вместе с подсистемой в PostgreSQL 11, у всех трёх контекст — пользовательский, и все три выражены в единицах стоимости планировщика — той безразмерной валюте, привязанной к seq_page_cost = 1.0. Когда планировщик завершает план, он сравнивает общую оценочную стоимость плана с этими порогами и запечатывает результат в сам план. Стоимость выше jit_above_cost (по умолчанию 100000): компилировать выражения и деформирование кортежей. Выше jit_inline_above_cost (по умолчанию 500000): также встраивать тела встроенных функций и операторов, извлекаемые из биткода LLVM, установленного вместе с сервером. Выше jit_optimize_above_cost (тоже 500000): также прогонять дорогостоящие проходы оптимизации LLVM по результату. Установка любого из них в -1 отключает этот уровень; jit_above_cost = -1 отключает всю затею, поскольку два других уровня надстраиваются над первым.
SQL Server содержит несколько встроенных математических функций, которые позволяют разработчикам выполнять сложные вычисления непосредственно в запросах. Среди них имеются такие тригонометрические функции, как SIN(), COS() и TAN(), полезные в сценариях, которые включают инженерные расчеты, обработку географических данных, моделирование и аналитику.
Хотя эти функции довольно просты в использовании, разработчики время от времени сталкиваются с неожиданными результатами при работе с углами и тригонометрическими вычислениями. Во многих случаях проблема связана не с самой функцией, а с тем, как SQL Server выполняет преобразование типов данных, и с точностью вычислений с плавающей запятой.
В этой статье рассматриваются несколько практических примеров, демонстрирующих поведение тригонометрических вычислений в SQL Server. Мы также исследуем несколько распространенных ошибок и покажем, как небольшие изменения, такие как выбор правильного типа данных или результаты округления, помогут избежать сбивающего с толку вывода.
Продолжить чтение "Тригонометрические функции T-SQL в SQL Server"
Высокая доступность критически важна для сред логической репликации, но до недавнего времени переключение при сбое всё ещё могло оставлять подписчиков отключёнными от слотов репликации, от которых они зависят. PostgreSQL 17 решил это, представив синхронизацию слотов при переключении при сбое, что позволяет держать слоты логической репликации готовыми на резервных серверах и снижает потребность в полной пересинхронизации подписчиков после повышения.
PostgreSQL 19 развивает эту основу с помощью повторно-осведомлённой ручной синхронизации и более ясной видимости пропущенных попыток синхронизации слотов. В этой статье мы рассмотрим, как работают эти возможности и как вклад команды разработчиков PostgreSQL из Fujitsu помогает сделать переключение при сбое логической репликации более надёжным и простым в эксплуатации.
Узнайте, как PostgreSQL улучшает синхронизацию слотов при переключении при сбое для логической репликации, повышая надёжность и сокращая время простоя при переключениях.
Мы приступили к массиву к семейства jit_*, и здесь алфавит перестаёт быть полезным редактором. Строгий порядок поставил бы пороговые значения стоимости перед концепциями, которые они ограничивают, и оставил бы jit_provider в одиночестве на дальнем конце, поэтому для этого семейства мы идём логическими кластерами: сегодня переключатель и движок, затем пара, решающая, что компилируется, затем три порога стоимости, а отладочные переключатели — в конце.
Продолжая проходить семейство jit_* в логических кластерах: эта пара решает, что именно компилирует JIT, и вы уже видели их имена, потому что это те самые «Expressions true, Deforming true», напечатанные в каждом блоке JIT, который показывал прошлый пост. Оба — логические, контекст — пользовательский, по умолчанию включены, часть исходной работы над JIT в PostgreSQL 11, и помещены в раздел «Параметры разработчика» — раздел документации, который идёт с постоянным предупреждением «не для производственной базы данных».
Параметры io_*, которые мы рассматривали до сих пор, описывают сами запросы ввода-вывода: насколько велик каждый из них, сколько процесс может держать в полёте. Эти два решают, кто фактически их выполняет. Я писал об архитектуре и о том, что PostgreSQL 19 с ней делает, в статье AIO Grows Up; здесь — взгляд на уровне параметров, и он включает исправление того, что я там сказал.
effective_io_concurrency — это запрос. io_max_concurrency — это удовлетворение.
Новый в PostgreSQL 18 как часть подсистемы асинхронного ввода-вывода, io_max_concurrency представляет собой жёсткий потолок того, сколько операций ввода-вывода один процесс может иметь в полёте одновременно. Не на весь кластер; на процесс. Контекст — postmaster, поэтому для изменения требуется перезапуск, а значение по умолчанию — -1, что указывает PostgreSQL выбрать значение при запуске. Диапазон простирается до 1024.
«База данных зависла». Мы слышали ту или иную версию этого предложения не раз за прошедшую неделю, от одной и той же команды, по поводу того, что выглядело как одна и та же проблема. Это была не одна и та же проблема. Однажды Postgres действительно перестал отвечать. Все остальные разы Postgres был в порядке, а соединение, находившееся в пуле приложения, тихо умерло где-то между приложением и базой данных.
Обе неисправности приводят к одному и тому же вызову в 2 часа ночи: приложение не может связаться с базой данных. Только одна из них означает, что база данных действительно в беде. Путаница между ними стоит вам самого дорогого ресурса в инциденте — первых десяти минут, когда вы ещё решаете, с каким типом проблемы имеете дело.
Истинное зависание PostgreSQL означает, что сам сервер перестал отвечать на уровне операционной системы. Вы не можете открыть новую сессию к нему, ни с какого клиента, ниоткуда. Проблема устаревшего соединения означает, что Postgres здоров и доступен. Проблема в конкретном соединении, уже находящемся в пуле вашего приложения, которое указывает на сокет, умерший где-то по пути, обычно без того, чтобы какая-либо из сторон получила чистый сигнал о том, что это произошло.
Теперь мы вступаем во владения io_* — самую новую в пространстве имён GUC: ничего из этого не существовало до PostgreSQL 17. Если effective_io_concurrency отвечает на вопрос «сколько операций ввода-вывода мы держим в полёте?», то io_combine_limit отвечает на ортогональный вопрос: «какова величина каждой из них?» Глубина и ширина.
Автор Christophe Pettus: https://thebuild.com/blog/all-your-gucs-in-a-row-intervalstyle/
IntervalStyle — младший «брат» DateStyle, и он унаследовал семейную черту: он выглядит как предпочтение форматирования вывода, но также меняет то, как PostgreSQL разбирает ваш ввод. Мы рассматривали версию даты этого трюка в статье про DateStyle. Версия для интервалов менее известна и в одном конкретном случае более неприятна.
