vreitech

Отсутствие реакции на SIGTERM при продолжающемся потреблении CPU это примечательно. Но без -dbgsym и GDB ничего определённого выяснить фактически не удастся. Суть - как-то попали в какую-то ветвь кода, которая не считалась что может занимать продолжительное время и вызов обработчика сигналов CHECK_FOR_INTERRUPTS там не был предусмотрен. Из вариантов навскидку где возможно в 16.х наступить - dblink или fdw, create index using hash. Традиционно, ещё могут быть index scan по gin или gist, не в первый раз находятся у них такие грабли.
Как минимум, удостовериться, что используется свежая минорная версия. Завтра 16.9 выходит.

Ну, это из предположения что весьма подозрительный watchdog: BUG: soft lockup тут ни при чём. Что это такое я вряд ли подскажу. Выглядит нехорошо.

Такс, это всё про оставшийся процесс.
Про сам the database system is shutting down
При crash recovery делается immediate stop, все backend которые не завершаться за 5 секунд получат SIGKILL. Который, естественно, проигнорировать уже не могут, потому что процессу про SIGKILL никто даже и не скажет, его просто снимет ядро ОС.
Значит, перед всеми the database system is shutting down был received smart shutdown request или received fast shutdown request, который кто-то скомандовал явным образом. Оба режима штатного выключения не делают SIGKILL, а именно дождутся корректного завершения процесса. В случае с багом, когда процесс не отреагировал на SIGTERM, ну, вечно ждать и будет. Других вариантов кроме SIGKILL тут нет.

Если логи ещё сохранились на дату shutdown request - то смотреть что там делали с системой, что кто-то скомандовал stop или restart базе. Если не вмешательство администратора, то может быть какой-то аналог unattended-upgrades?

Якорный метасимвол \G в PHP и Ruby соответствует началу текущего совпадения, а в Perl. java.util.regex и языках .NET – концу предыдущего совпадения.
В подавляющем большинстве случаев конец предыдущего совпадения и начало текущего совпадения это одно и то же, но в некоторых редких случаях эти две позиции могут различаться.

https://www.rexegg.com/regex-anchors.php#G

Например, строка A=1:2:3 B=1:2:3 A=1:2:3:4:5 B=1:2:3

Шаблон поиска ((?:A=|\G)\d):
Строка замены $1.

Результат A=1.2.3 B=1:2:3 A=1.2.3.4.5 B=1:2:3

https://regex101.com/r/nuWRBb/1

Как работает \G подробнее в книге Джеффри Фридла "Регулярные выражения".

Улучшает, если этот размер MTU поддерживается на всём пути между сервером и клиентом. В противном случае - ухудшает.

Лучше не надо

UPD
Появилось некое решение supercronic - ещё не тестировал, но судя по описанию выглядит перспективно.

SELECT * FROM base WHERE domain LIKE '%habr%' LIMIT 10000;

проще всего так, наверно:

CREATE EXTENSION pg_trgm;

CREATE INDEX trgm_domain_base_idx ON base USING GIST (domain gist_trgm_ops);

EXPLAIN ANALYZE SELECT * FROM base WHERE domain LIKE '%habr%' LIMIT 10000;

https://www.postgresql.org/docs/current/pgtrgm.html

домен лучше приобрести сразу, хотя это не необходимо, но стоит копейки, когда созреете - его займут.
а по неймингу в АД отвечал давно тут
Плоское имя типа "KITRUS" как рекоммендуют выше, так же не исползьуйте.

Каждое из приложений должно понимать, что оно работает по адресу /webX. Если не понимает, возможны перенаправления на url, которые вы не учли. В целом, для современных сложны приложений, так работать не будет.

Блокировки строк и блокировки таблиц (и прочих объектов) - два разных механизма. (а serializable изоляция и вовсе частично третий)

Блокировки строк отмечают информацию о себе специальными флагами в заголовке самой заблокированной строки. Запросы, которым нужна блокировка строки сначала проверяют, не отмечена ли эта строка блокировкой, затем проверяют что сейчас с той транзакцией, идентификатор transaction ID которой указан в информации о блокировке. Если транзакция ещё в работе - то начинаем ждать её завершение (или пропускаем строку для skip locked или кидает ошибку если nowait)
Блокировки строк, будь то select for share/for update или пишущие запросы, всегда работают с самой актуальной версией строки.

В то же самое время, любой запрос, трогающий таблицу (даже select) берёт блокировку на эту таблицу соответствующего своим потребностям уровня. Пока не возьмёт блокировку на таблицу - вообще не начнёт выполняться. Информация об этих блокировках размещается в сегменте shared memory памяти, потому доступны всем процессам базы. Если другие бекенды не держат блокировку таблицы конфликтующую с желаемым нашей транзакцией (или ещё только ждут блокировку более высокого уровня), то запрос блокировки удовлетворяется и работа продолжается.

ip --json link | jq -r '.[]|select(.operstate=="UP").address'

Какой отечественный linux выбрать для веб-разработки?

Никакой. Для web-разработки абсолютно фиолетово какой у тебя Linux, отечественный или нет. И если нет какой то особой осознанной нужды в использовании именно отечественных изделий, то лучше держаться от них подальше.

https://www.postgresql.org/docs/current/sql-syntax...
соответствовать синтаксису идентификаторов.

Если кавычек нет, то предполагается, что без учета регистра. Грубо говоря, без кавычек - все в нижний регистр.
В данном случае, надо добавить кавычки вокруг имени пользователя:
CREATE USER "PolzaK" WITH PASSWORD

Но учитывай, что тебе и дальше придется всегда указывать кавычки. В противном случае,
ALTER USER PolzaK ...
Тоже самое, что и
ALTER USER polzak ...