Я это читал, потому и вопрос в диссонансе того что написано в документации, и того что вижу в выводе патрони и той системной вьюшки

synchronous_standby_names у вас определено?

да, указана реплика

В предположении, что задана синхронная репликация, параметр application_name в файле recovery.conf и параметр synchronous_standby_names в файле
postgresql.conf, параметр synchronous_commit открывает следующие возможности:
 off: это, по существу, асинхронная репликация. Журнал транзакций на
главном сервере не сбрасывается на диск мгновенно, и главный сервер
не ждет, пока резервный запишет данные на свой диск. Если главный
сервер выйдет из строя, часть данных может быть потеряна (за время,
в три раза превышающее wal_writer_delay);

(с) PostgreSQL 11 Мастерство разработки

В предположении, что off: это, по существу, асинхронная репликация, почему в pg_stat_replication sync_state = sync ? Как-то нелогично и вводит в заблуждение.

Ну так реплика - синк. Т.е. инфа до реплики доехала, реплика ответила, что она на месте, но место - это буферы ПГ, а не диск. Вот и получается, что реплика де-юре - синхронная, а де-факто - асинхронная.

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

> Как-то нелогично и вводит в заблуждение.

На самом деле, это логично.

> Я это читал

Вот это лучше прочитайте:
https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT
(объяснение такого поведения — в последнем параграфе, если что ;) ).

>>  де-юре - синхронная, а де-факто - асинхронная.

Ничему нельзя верить, всё нужно перепроверять)
В общем спасибо всем.

ВНЕЗАПНО! :)
А ещё совсем не мешает ВНИМАТЕЛЬНО читать документацию, точно говорю. А если ещё и осмысливать прочитанное, то жизнь становится совсем радостной. :P

ну вот так на опыте и осмысливается, ага.

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

Кажется логичным это сделать за одну перезагрузку. Разве нет?

Ну пусть одна будет, ок. Вопрос больше в том как грамотно и по правильному сохранить именно изменения за последнюю неделю, к примеру. Чтобы потом в обслуженной БД внести эти изменения.

Не знаю. Сама постановка задачи мне кажется неграмотной.

Ок, тогда задача: сделать вакуумфул БД, он будет длиться 4 дня. Как это грамотно сделать? Ведь пользователям не скажешь что сервис не будет 4 дня работать

Я это вижу так: копирую БД, обслуживаю 4 дня и накатываю последние изменения, внесённые пользователями

О, до сверхзадачи добрались.
Сделайте вакуум и реиндекс конкурентный.

Что значит конкурентный?