Melkij

FDW, dblink, pg_dump, copy to/copy from, написание отдельного скрипта на любом прикладном языке - что вам проще и какая возможность доступна - так и делается.
Лишь только не перепутать местами источник и целевую базу.

Например, на восстановленной базе переименовать табличку, pg_dump -t имя_таблички, импортировать в боевую базу
Или взять pg_dump -s -t проблемная табличка, \copy в локальный файл данных, \copy из файла в пустую временную табличку
А имея под рукой рядом оригинальную и восстановленную табличку уже править данные в ней

Без разницы. У них один и тот же источник данных. Можно и напрямую pg_stat_get_db_numbackends(oid) вызвать.

В production для мониторинга обычно используется pg_stat_activity чтобы сразу забрать группировку по статусам backend'ов, длительность активных транзакций. Ну и скорее всего только client backend будут интересны на этом графике (ну возможно ещё с parallel worker'ами). Для процессов autovacuum удобнее отдельный график иметь.

После, с параметрами которые отрабатывали 3-6 секунд, запрос выполняется с нормальной скоростью в ms

Симптоматика медленного чтения с дисков.
Поставьте pg_stat_statements, включите track_io_timing и посмотрите в blk_read_time, blk_write_time этого запроса относительно числа вызовов и общего времени их выполнения.

PS: обратите внимание, что для СУБД критична латентность дисковой системы. Есть графики латентности io на чтение и запись?

А вы уверены, что это PDO меняет регистр, а не сама база делает то, что предписывает SQL стандарт? unquoted identifier регистронезависим. Приводить идентификаторы к единому регистру вполне предписываемое поведение. Правда, по стандарту идентификаторы приводить надо к uppercase.

Укажите quoted identifier
SELECT full_name as "fullName" FROM ....

hash индекс строится в один поток, для них многопоточный create index не делали. Потому загрузка 100% одного ядра - ситуация нормальная.
Нет, create index не зависает.
Если у вас селективность поля хреновая - то hash индекс будет строиться медленно, т.к. много строк попадает в одно и то же значение хеширования. Не помню точно, как именно хранится список TID при коллизиях хеш-функции, но точно работает хреново при большом числе дублей значений.

Если версия postgresql достаточно свежая - то смотрите pg_stat_progress_create_index системное представление. Там будут некоторый progress reporting.

Корректно - абсолютно никак. WAL критичная часть базы.

Некорректно, без всяких гарантий, но на clean shutdown базе можно надеяться без потери данных - pg_resetwal. Перед использованием сделайте бекап всего PGDATA ( /var/lib/postgresql/10/ut/ в вашем случае судя по пути до pg_wal). После старта базы - pg_dumpall и initdb всего кластера заново, как прямым текстом указано в документации к pg_resetwal.

как нужно было сделать по уму если валы от слота не удаляются при удалении слота.

Дождаться или сделать руками чекпойнт.

Забыть.
В pg_dump нет информации о физическом расположении данных. В WAL нет информации о логическом расположении данных - даже на wal_level=logical потребуется обращение к системным каталогам. В WAL грубо говоря записано "записать такие байты по такому смещению в файл"

https://www.pgbarman.org/barman-2-3-released/

5 September 2017: 2ndQuadrant is proud to announce the release of Barman version 2.3, a Backup and Recovery Manager for PostgreSQL.

This minor release introduces support for PostgreSQL 10.

PROGRAM в mdadm.conf можно задать

PROGRAM
The program line gives the name of a program to be run when
mdadm --monitor detects potentially interesting events on any of
the arrays that it is monitoring. This program gets run with
two or three arguments, they being the Event, the md device, and
possibly the related component device.

There should only be one program line and it should be give only
one program.

Написали, что last_name должно начинаться со строки [А-я] - так и проверяется.

melkij=> select '[A]ds' like '[A]%';
?column?
----------
t
(1 строка)

Куда вам query rewrite system, если вы регулярки от like не отличаете?
Зачем not valid лучше даже не буду спрашивать.

Предупреждение выводит настройка checkpoint_warning. Говорит о том, что вы создаёте так много wal, что срабатывают чекпойнты чаще величины этого варнинга. Это именно совет базы посмотреть внимательнее на конфигурацию и workload.

Выяснить, чем именно вы генерируете wal и, возможно, переосмыслить этот процесс. Смотрите, что у вас обычно работает в то время, когда срабатывают эти предупреждения. Какие-то массовые импорты данных, ещё что, пишущее много данных.
Возможно, вам нужно увеличить свой max_wal_size ещё дальше. Но учитывайте, что чем больше wal между чекпойнтами - тем дольше будет стартовать база после аварийного выключения, т.к. должна накатить все wal от последнего чекпойнта.
Это tradeoff между временем старта база при аварии и количеством IO при нормальной работе. Чекпойнт - это довольно много IO.

PS: спросите у базы "show max_wal_size;" точно ли настройка применена.

https://dbfiddle.uk/?rdbms=mysql_8.0&fiddle=f14773...
it works

Смотрите внимательно на текст ошибки и, особенно, на место на которое та указывает.