PostgreSQL уже записывает PID-файл. Каждый раз при запуске postmaster он помещает postmaster.pid в каталог данных и удаляет его при чистом завершении работы. Этот файл является блокировкой, которая предотвращает запуск второго postmaster с тем же каталогом данных, и содержит восемь строк с деталями работающего экземпляра: PID, каталог данных, время запуска, порт, каталог сокетов и так далее. external_pid_file не заменяет его. Он просит postmaster записать второй, гораздо меньший файл в другом месте.
На протяжении всей истории PostgreSQL до настоящего момента расширение должно было находиться ровно в одном месте. CREATE EXTENSION foo читал foo.control из встроенного каталога расширений, на который указывает pg_config --sharedir, и нигде больше не искал. Если вы хотели, чтобы расширение было доступно, его файлы должны были находиться в этом каталоге, что на практике означало установку от root в системное дерево или встраивание в образ. extension_control_path, новый в PostgreSQL 18, отменяет это допущение.
Когда люди говорят, что Python медленный, они обычно обвиняют язык.
В действительности это часто зависит от того, как мы пишем код.
Python является выразительным, читабельным и мощным. Но небольшие ошибки в структуре и обработке данных могут незаметно влиять на производительность...особенно в серверных системах или приложениях с большим объемом данных.
PostgreSQL сортирует свои проблемы по степени серьёзности. ERROR прерывает текущий оператор и откатывает транзакцию, но сессия продолжает жить; вы выполняете ROLLBACK и продолжаете работать. FATAL завершает сессию, разрывая это одно подключение, пока сервер работает дальше. PANIC останавливает весь сервер. В нормальной работе граница между «ваш оператор не выполнился» и «ваше подключение потеряно» проходит между ERROR и FATAL, и почти всё, что идёт не так в повседневном SQL — опечатка, нарушение ограничения, деление на ноль — является всего лишь ERROR.
9:12 утра в понедельник. Кто-то из вашей команды открывает каталог pg_wal/archive_status/ во время паники по поводу хранилища и видит длинный список файлов, оканчивающихся на .ready. Возникает вопрос, который многие из нас задавали хотя бы раз: «Сломалась ли репликация?» Потоковые реплики всё ещё выглядят в основном нормально, но файлы .ready продолжают накапливаться, использование диска продолжает расти, и никто до конца не уверен, что на самом деле означают .ready и .done.
Что такое .ready и какие (если вообще какие) действия мне нужно предпринять? Давайте поговорим об этом сегодня.
Подсказка: Это о доставке WAL
Представьте доставку WAL как три независимых шага:
Генерация WAL
Транспортировка WAL
Воспроизведение или потребление WAL
archive_command — это один из способов транспортировки. Потоковая репликация — другой. Обратите внимание, что логическая репликация также имеет канал транспортировки, но она транспортирует декодированные данные логических изменений, а не сырые файлы сегментов WAL.
Событийный триггер (event trigger) срабатывает на события базы данных, а не на изменения строк: на ddl_command_start, sql_drop, table_rewrite и, начиная с PostgreSQL 17, на login. Они используются для аудита DDL или наложения запрета на DDL, и они идут с хорошо известным способом выстрелить себе в ногу. Напишите триггер на ddl_command_start, функция которого вызывает исключение, и теперь каждая команда DDL в базе данных завершается ошибкой, включая DROP EVENT TRIGGER, который вы использовали бы для его удаления. Документация содержит ровно этот пример — функцию abort_any_command, настроенную на прерывание всего, предположительно для того, чтобы вы узнали форму ошибки, когда уже её совершили.
event_source — это параметр для Windows, что означает, что для большинства читающих это не делает ровно ничего. Если вы запускаете PostgreSQL на Linux или в управляемом сервисе, там нет журнала событий Windows, с которым он мог бы взаимодействовать, и эта строка навсегда остаётся со значением по умолчанию. То, что следует далее, предназначено для меньшинства пользователей Windows, и сводится к одному факту, который стоит знать.
Вы просто хотите посмотреть ваши данные. Вы быстро набираете display(df) в ячейке notebook и жмете Выполнить. Это кажется совершенно безобидно - кроме того, это всего лишь предварительный просмотр вашего фрейма данных, не так ли?
Но через несколько мгновений ваш кластер начинает вращаться, ячейка работает намного дольше, чем ожидалось, и ваш браузер может даже заикаться.
Хотя display() является фантастическим инструментом для интерактивного исследования, но, если слишком сильно полагаться на него, он может незаметно задушить ваши задания Apache Spark. Давайте заглянем под капот, чтобы точно выяснить, что происходит, когда вы вызываете display(), почему все замедляется, и как простое переключение на show() может радикально улучшить вашу производительность. Продолжить чтение "Любопытный случай с display(df)"
Существует распространённое заблуждение, которое беспокоит большинство разработчиков, использующих PostgreSQL: настройте VACUUM или запустите VACUUM, и ваша база данных останется здоровой. Мёртвые кортежи будут очищены. Идентификаторы транзакций переработаны. Пространство освобождено. Дальнейших действий не требуется.
Но есть пара «грязных» секретов, о которых люди не знают. Первый из них заключается в том, что VACUUM лжёт вам о ваших индексах.
escape_string_warning включён по умолчанию уже около двадцати лет, и на современном PostgreSQL, настроенном обычным образом, он никогда не скажет вам ни слова. Это не неисправность. Условие, о котором он предупреждает, перестало быть поведением по умолчанию в 2011 году.
enable_tidscan — это параметр enable_*, который вы почти наверняка никогда не установите, и на этот раз это не предупреждение, а просто факт о том, как происходят сканирования TID. Вы не натыкаетесь на него случайно, как на последовательное сканирование или сортировку. Сканирование TID появляется только тогда, когда вы явно написали условие на ctid, поэтому тип плана, которым управляет этот параметр, появляется именно тогда, когда вы его запросили, и никак иначе.
(Для протокола: я за всю свою жизнь ни разу не видел узел tidscan.)
В статье о HOT-обновлениях в Postgres мы рассмотрели, как обрезка страниц (page pruning) очищает HOT-цепочки — элегантное сокращение, с помощью которого PostgreSQL освобождает место мёртвых кортежей во время обычных операций чтения. И всё это без ожидания фонового процесса. Но обрезка — это именно сокращение. Она работает только в пределах одной страницы и только для кортежей, обновлённых через HOT. Для всего остального (холодные обновления, затрагивающие индексированные столбцы, обычные DELETE, очистка записей индексов, регистрация в карте свободного пространства, обслуживание карты видимости) необходим VACUUM.
Эта статья не будет повторять то, что VACUUM делает с эксплуатационной точки зрения. Статья DELETEs are difficult охватывает настройку autovacuum, распределение рабочих процессов и эксплуатационную сторону очистки мёртвых кортежей. Здесь мы будем наблюдать за работой VACUUM побайтово. Мы сделаем снимок страницы до и после каждого этапа, отслеживая, что именно меняется в заголовке страницы, указателях строк, заголовках кортежей, карте свободного пространства и карте видимости. Инструменты всё те же: pageinspect, pg_visibility и pg_freespacemap.
Обращение к enable_sort = off, потому что в запросе есть медленная сортировка, обычно бьёт мимо цели. Когда сортировка медленная, это обычно происходит из-за того, что она сбрасывается на диск, что является проблемой work_mem. Если сортировки вообще не должно быть, исправление — это индекс. enable_sort не изменяет ни одного из этих факторов, и его отключение редко бывает тем, что вам действительно нужно.
