Блин, вот эти 5 мелких табличек все испортили - раз в 30мин спавнятся воркеры которые делают COPY в них и крашатся, тк в них уже есть ключи которые мы пытаемся вставить.

И не могу сделать им TRUNCATE, так как на одной из этих табличек в которой всего 5 записей, держится fkey из многотерабайтной таблицы которая уже скопировалась...

Безопасно ли дропнуть fkeys с большой таблицы, сделать truncate этим мелким табличкам, и пересоздать fkey как NOT VALID? Очено не хочется что-то необратимо сломать и начинать весь процесс с начала...

Потом добавлять назад ключ может быть долго.
А так особых противопоказаний нет.

Но мне кажется можно обойтись без этого.

Смею предположить, что проблема в рассинхронизации секвенций для первичных ключей.

Там конфликты ключей на табличках вот такого размера, а эта например вообще без секвенции:

select * from language_type;
 id |    name
----+-------------
 A  | Ancient
 C  | Constructed
 E  | Extinct
 H  | Historical
 L  | Living
 S  | Special
(6 rows)

Time: 1.787 ms

Такое чувство что постгрес сделал COPY в первый раз и забыл, и теперь вместо того чтоб просто начать читать WAL он запускает COPY во второй раз для этой мелкой таблицы...

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

Ну, скорее всего неосторожное обращение с репликацией.

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

Вот бы еще такой вид/квери иметь, чтоб для каждого релейшона в репликации отображало статус (COPY/streaming wal) и в каком статусе находятся воркеры. И еще метрику IOWAIT к каждому воркер процессу!

ALTER SUBSCRIPTION mysub DISABLE; из доков не очень понятно - ВАЛы потеряются или нет, когда я снова сделаю ENABLE на этой подписке?

Я часа 4 назад остановил почти всю запись на мастере, и с тех пор у меня на реплике висят 6 воркеров ожидающих ВАЛы с ожиданием LibPQWalReceiverReceive. Еще wal_receiver_timeout у меня была 12h, сейчас поменял на 10min. Я слелал DISABLE этой подписке, но воркеры все еще висят...

Как от них избавиться? pg_terminate_backend безопасно сделать? Или может CHECKPOINT; на мастере?

Аааааа, сделал DISABLE подписке, pg_terminate_backend всем воркерам на реплике, очистил эти мелкие таблички пересоздав констрейнты, делаю ENABLE подписке и получаю спам из сообщений:

logical replication table synchronization worker for subscription ""core0_denali"", table ""company_type"" has started
could not create replication slot ""core0_denali_17708_sync_16475"": ERROR:  replication slot ""core0_denali_17708_sync_16475"" already exists

Хелп, что можно сделать? Я понимаю слоты это воркеры на мастере, их опасно убить?

Все эти воркеры на мастере ожидают лока на transactionid, с квери BEGIN READ ONLY ISOLATION LEVEL REPEATABLE READ. Причем все они запущены в одно время, xact_start такой же как и у воркеров с реплики которых я кильнул.

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

в первое время может возникать небольшой шторм, зависит от кол-ва данных в репликации, но после все ОК

Спасибо, я бы и сам рад был пересоздать всю подписку, но база дико большая чтоб ждать еще неделю-две...

Оказалось что на мастере воркеры висели в ожидании лока, который держал один из клиентов) Я этого клиента кильнул и слоты пересоздались. Вроде бы все ок сейчас.

вот статья, может помогать при разборках с логической репликацией
https://elephanttamer.net/?p=43

Update jui_discard jd
   set discard_place = rlo.title
from jui j
  left join ref_location_organ rlo on j.organ_id = rlo.id
where  (jd.jui_id = j.id)
 and jd.created_at >= '2020-12-31'
 and jd.discard_place is null
 and j.movement_point_id = 2011

Народ может кто нибудь понять в чем дело

почему она не запускается

даже ошибку не выкидывает