Melkij

https://github.com/2ndQuadrant/pglogical/blob/REL2...
Попробуйте указать запрос с полным наименованием таблицы.
Вероятно в схеме public у вас таблица:

SELECT pglogical.replicate_ddl_command('ALTER TABLE public.aaa_plc_banned_domains ADD Phone2 CHARACTER VARYING(20)');

Для начала понять, нафига вам вообще нужная база в докере. Раз нужны бекапы - то очевидно база нужная. Не раз видел нужные базы без бекапов, а вот настроенных бекапов для ненужных - как-то не припоминаю. А раз нужная база - то зачем здесь докер? Внимательно осмыслить этот вопрос. Если сможете удивить меня - буду весьма благодарен, до сих пор ни один из опрошенных адептов докера с таким простым вопросом не справился.

Ну а далее определитесь с требованиям к бекапам. Глобально возможности есть две, и обе никак не относятся к тому, где размещены бинарники базы. Можно выполнять вообще с другого хоста по сети.
Во-первых, можно периодически снимать логический дамп данных с помощью pg_dump или pg_dumpall. Плюс: они компактнее, обычно сильно компактнее, плюс неплохо сжимаются, для форматов custom и directory возможно восстанавливать объекты выборочно, например только одну таблицу. Можно бекапить отдельные базы, исключать из дампа что-нибудь ненужное. Минусы: существенное время восстановления, в частности из-за необходимости построения всех индексов; восстановление возможно только на момент начала снимания дампа.
Во-вторых, можно снимать бинарную копию и вести журнал WAL. Плюсы - возможность восстановления базы на произвольный момент времени от окончания pg_basebackup и до тех пор пока есть непрерывный архив WAL. Но basebackup занимает ровно столько же места сколько кластер, плюс архив WAL. Бекапить можно только весь кластер целиком. Восстанавливать так же можно только целиком.
Чтобы не собирать самостоятельно вся обвязку вокруг pg_basebackup, посмотрите pgbackrest, barman. wal-g можно для хранения в s3.

Вполне осмысленно можно использовать оба способа одновременно, архив wal для point-in-time recovery, а так же например раз в неделю/месяц логический дамп для более долговременного хранения. Бывает порой такое, а "давайте восстановим годовой давности табличку".

Так переинициализировать или перенести на другой хост?

переинициализировать - удалить директорию, сделать initdb.
перенести на другой хост - выключить базу, скопировать весь PGDATA целиком включая всё содержимое по всем симлинкам, запустить базу. Либо вызвать штатный pg_basebackup и им скопировать запущенную базу (по протоколу репликации).
Возможно только на той же аппаратной архитектуре.

Если вы говорите именно о view - то я вас вовсе не понимаю.
В view в принципе нет и не может быть ни одной строки, в сам view невозможно ничего записать (writable view - это переписывание запроса). Когда вы обращаетесь к view - в запрос идёт запрос из объявления этого view и весело анализируется/переписывается как любой другой запрос.

То есть что с чем вы пытаетесь синхронизировать? Запрос с другим запросом? У вас данные всего в одном месте, нечего синхронизировать здесь.

Если вы говорите всё-таки о материализованном представлении - то вам нужен отдельный запрос refresh materialized view. Вообще matview by design для неактуальных данных и задаче периодической актуализации через refresh.

Запрос в вопросе делает cross join views на items и разумеется данные в результате будут совершенно верные, но бессмысленные.

Не думаю, что перебирать потенциально большие views и items полностью не прокидывая заведомо известные условия поиска по датам - хорошая мысль даже для аналитического запроса.

select d as day,
(select count(*) from views where created_at >= d and created_at < (d + interval '1 day')) as views_count,
(select count(*) from items where created_at >= d and created_at < (d + interval '1 day')) as items_count
from generate_series('2018-12-26'::date, '2018-12-30', '1 day' ) as dates(d)
order by day desc

Либо похожим образом

select d as day, views_count, items_count
from generate_series('2018-12-26'::date, '2018-12-30', '1 day' ) as dates(d)
left join lateral (select count(*) as views_count from views where created_at >= d and created_at < (d + interval '1 day'))  as v on true
left join lateral (select count(*) as views_count from items where created_at >= d and created_at < (d + interval '1 day'))  as i on true
order by day desc

И посмотреть, что по этому поводу думает планировщик

json_agg есть нативный, если я верно понял о чём вы.

Никак. Реплика строго readonly.

Например,

insert into order_product_link (order_id, product_id) select 1, i from unnest(array[1,4,7,86]) as i;

Как передать массив из go в массив postgresql - не подскажу. Уточняйте в используемой библиотеке go.

Или copy from stdin и шлёте столько строк в copy сколько надо.

В таблице есть столбец с данными типа timestamp.
Время там хранится UTC

Мигрируете на timestamp with time zone
Затем проставляете желаемый set timezone to '...'; и получаете всю обработку для timestamp with time zone корректную в этом часовом поясе.

не красиво перечислять их все ради того, чтобы скорректировать один.

Красиво - это перечислить явно и только те поля, которые в результате вам нужны.
Если в этом дурацком засилье orm вы пишете запрос руками - значит вы явно должны знать, что именно и зачем вы хотите прочитать. Следовательно, select * показывает явный антипаттерн.

Долго и мучительно раскуривайте эту кладезь бреда и авгиевы конюшни говнокода под названием 1с.
Эти люди в принципе не умеют работать с СУБД. И в базе там абсолютный ад и бардак, всё верно.

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