Похоже происходит какое-то замыкание связей

Небольшая табличка из логической репликации все еще не завершила initial COPY. постгрес спамит в логах что чекпоинты случаются слишком часто и советует повысить max_wal_size который и так 1G. completion target = 0.9, wal timeout = 15min. В чем может быть дело? Я остановил почти всю запись на мастере которая касается этой репликации, поэтому логов должно быть минимум. Тем не менее пару раз в минуту получаю сообщение о том что чекпоинты случаются слишком часто!

Ничего он такого не "говорит" — прочитайте сообщение внимательно.

> постгрес спамит в логах что чекпоинты случаются слишком часто

В логах базы-источника?

> советует повысить max_wal_size который и так 1G.

Это совсем немного. ;)

> поэтому логов должно быть минимум.

Тем не менее, что-то пишет — можете проверить статистику (хоть pg_stat_database / pg_stat_all_tables), а можете просто "посмотреть" какие-то сегменты WAL с помощью pg_waldump на предмет того, что же (куда же) пишется.

>В логах базы-источника?
Не, в логах сервера которай принимает логическую репликацию.

>Тем не менее, что-то пишет — можете проверить статистику (хоть pg_stat_database / pg_stat_all_tables), а можете просто "посмотреть" какие-то сегменты WAL с помощью pg_waldump на предмет того, что же (куда же) пишется.

Благодарю, посмотрю!

странно, сами волы почему-то размером 16МБ а не 1ГБ

они по-умолчанию такие

Да, конечно — это же размер сегмента по умолчанию.

> Не, в логах сервера которай принимает логическую репликацию.

Тогда что Вас удивляет вообще? Может быть, это попадает в WAL тот самый initial COPY?
Что такое "небольшая"? 10 или 100 гигабайт?

можете подсказать как исправить ошибку < 2021-02-08 08:38:37.026 MSK >FATAL:  the database system is starting up
База один инстанс

Добавил табличку 80 GB в логическую публикацию и рефрешнул ее на подписчике, но она копируется со скоростью 100КБ/сек уже третьи сутки, такую скорость iotop показывает. Причем на мастере куча OLTP процессов которые используют гораздо больше IO, а walsender для COPY этой таблицы съедает лишь долю процента.

Таблица на практически полностью ридонли, но на всякий случай чтоб промыть грязные буферы я сделал select count(col) на мастере, и квери завершилась очень быстро.

Только ждать и надеяться что запутсится

Казалось бы, сервер запускается — ждите. Или можете его логи посмотреть.

уже час

в логах кроме ошибки выше пусто

Это нормально! В следующий раз когда останавливаете сервер, делайте это в режиме smart и закрывайте долгоживущие коннекты вручную через заранее открытую сессию.

Этого просто не может быть. Там должна быть информация о начале запуска (возможно, это ротация логов Вам "удружила"?).

Она по факту пытается восстановить базу ? Поврежденные файлы

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

А полные версии PostgreSQL там и там какие?

> такую скорость iotop показывает.

Да что он вообще может знать о процессах postgres?! ;)
И я серьёзно, между прочим — запись в WAL такой процесс будет стараться откладывать — "за него" её почти наверняка будет выполнять что-то другое (тот backend, который делает свой commit); а запись в базу — checkpointer (на который Вы и видите жалобы в логах).