Melkij

А зачем?
https://www.linuxatemyram.com/

Почему банальное создание не срабатывает и зависает ?

Потому что известное задокументированное ограничение имеющейся реализации.
https://www.postgresql.org/docs/14/sql-createsubsc...

Creating a subscription that connects to the same database cluster (for example, to replicate between databases in the same cluster or to replicate within the same database) will only succeed if the replication slot is not created as part of the same command. Otherwise, the CREATE SUBSCRIPTION call will hang. To make this work, create the replication slot separately (using the function pg_create_logical_replication_slot with the plugin name pgoutput) and create the subscription using the parameter create_slot = false. This is an implementation restriction that might be lifted in a future release.

Как можно заметить, актуально и для pg18. Мешает? Напишите патч. Пока что, очевидно, никому не мешает в достаточной степени чтобы заняться исправлением. Подписка из одной базы в другую в пределах одного и того же кластера штука довольно редкая.

Кто сталкивался , можете посоветовать куда копать и что проверить еще , что еще этой базе надо? Почему падает этот воркер у шефа?

Нужны остальные логи (и с подписчика и с публикации).
Можно начать с проверки, что там в конфиге было изменено. Может логирование ограничено.

Начать желательно с документации. https://dev.mysql.com/doc/refman/8.4/en/show-repli...
То есть вы неверно понимаете эти значения.

SQL_Delay

The number of seconds that the replica must lag the source.

SQL_Remaining_Delay

When Replica_SQL_Running_State is Waiting until SOURCE_DELAY seconds after source executed event, this field contains the number of delay seconds remaining. At other times, this field is NULL.

SQL_Delay - это намеренная задержка репликации как минимум на такой срок: https://dev.mysql.com/doc/refman/8.4/en/replicatio...
SQL_Remaining_Delay показывает сколько времени осталось ждать до применения следующей транзакции, только в том случае когда мы ждём сконфигурированную задержку репликации. timestamp выполнения транзакции на источнике мы заведомо знаем, до него и показывается остаток.

И то и другое отображает намеренно сконфигурированное администратором поведение и поэтому не может быть проблемой по своему определению.

Масштаб проблемы: критично, этим кластером (в терминах postgresql) пользоваться нельзя. Разбираться с тем как делаются бекапы, как восстанавливались и где именно сделали неверно. Системный каталог не соответствует файловой системе. Можно ожидать любые аномалии помимо отличий relfilenode. Например, полностью сломанный mvcc.

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

Никуда.
Вы смотрите на, по своему определению, приблизительное значение. 700к или 900к - значения одного порядка, допустимая флуктуация для статистики планировщика.

об этом раньше было отдельная сноска в интерфейсе phpmyadmin, не знаю как сейчас. Никто не пересчитывает всю таблицу, чтобы узнать, 895342 там записей или 902542 записей.

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

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

Отсутствие реакции на 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?

Transactional Information Systems, by Gerhard Weikum and Gottfried Vossen, Morgan Kaufmann

открываете свой ss -lutnp и изучаете, точно ли вы хотите это всё выставлять доступным извне.

Вернее лучше сказать так - могут ли быть какие-нибудь слушающие порты каких-нибудь программ, способных уничтожить систему или слить данные удаленно?

вероятность RCE ненулевая, не говоря уж о том же ssh с разрешённой парольной аутентификации но слабым паролем