Melkij

update tablename set jsoncol = cast(cast(data as json)#>>'{}' as json);

Можно ли делать resize диска без остановки работы СУБД

Да.
postgresql использует рядовые sysctl работы с файлами и не взаимодействует с устройством напрямую.

плюс надо рестартить базу чтобы они заработали

С чего вы так решили?

В момент выполенния запроса от текста запроса уже ничего не остается, он распаршен.

Да щас. Заботливо хранится, т.к. может потребоваться для того же логирования.

Выполняющийся в данный момент запрос клиента можно достать откуда угодно (в том числе из триггера) вызовом current_query().
Конкретную таблицу логировать удобнее да, триггером.

Не надо так делать.
https://use-the-index-luke.com/sql/where-clause/ob...

Не включайте в запрос условие, если его там не должно быть.

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 на чтение и запись?

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.

Написали, что 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;" точно ли настройка применена.