А, вы хотите одновременно и с мастера и с реплики подписку делать?

Подумайте тогда, как решать конфликты псевдо-мультимастера, который у вас получается

нет, я хочу что бы после переключения роли на публикующем сервере подписчики не отваливались с ошибкой о недоступности слота

Делайте каскад со стендбая

Вы не сможете сделать реплику одной таблицы из двух источников только средствами postgres

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

Вот вам совет: не читайте больше там, где пишут такую чушь.

> чтобы выборка через равенство ( на вход в запрос подавать user_id, status ), работала оптимально

Для подобных условий (равенство по всем) любой порядок полей в индексе одинаково эффективен.

Почему из из двух источников?
Источник один, публикующий сервер (его мастер-нода).

А какой механизм вообще может скрываться под этим "очевидно", ради любопытства? ;)

Я не DBA - вряд ли подскажу тонкости. Но я всегда считал, что чем больше PostgreSQL может отбросить записей сразу же - тем оптимальней будет выполняться запрос. То есть если бы сначала шёл статус, то по статусу active (например), записей бы было сильно больше, чем если бы сначала был id юзера, т.к. для id юзера в той таблице (скорее всего) записей было бы сильно меньше. То есть искать сразу по id юзера будет эффективней, т.к. меньше записей надо будет просмотреть.

Ещё раз. Слот репликации в том числе блокирует удаление не вычитанные репликой wal. Вы создаёте висящий слот, который никто не читает. Вы точно этого добиваетесь?

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

> Я не DBA - вряд ли подскажу тонкости.

При чём тут, извините, DBA?!
Вы предмет "алгоритмы и структуры данных" (кажется, так называется) на котором должны проходить и b-trees, помните?
Как, ну как порядок полей в ключе B-дерева может влиять на его эффективность при выборках на равенство в принципе?!

> Но я всегда считал <skip>

Да. Только вот b-tree работает совсем не так, как Вы написали далее.

Зайдем с другой стороны, сервер который был мастером стал репликой, и он показывает неактивные слоты.
Что с этим делать?
Руками удалить?

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

Хотя вру - проходили, правда не контексте баз данных и индексов

Странно, вроде там при изложении специально разделялись алгоритмы и структуры данных для внутренней и внешней памяти... может, программу в какой-то момент "улучшили", кто его знает. ;(

Не буду наговаривать на университет, в котором учился: я мог просто забыть)

Если реплика стала мастером, то либо старый мастер умер, либо у вас split-brain и надо что то делать с кластером целиком. В первом случае слоты уже не важны, во втором - зависит от принятого решения. Старый мастер автоматически репликой не станет

ребят, что делать? - было поле 'X' unique (часть составного pk), на него был fk. Теперь поле 'X' не может быть unique, следовательно прощай fk?

> было поле 'X' unique (часть составного pk)

Я не совсем понял, как это (либо это нарушение 2NF прямо тут), но, в общем, да — FK должен ссылаться на не-частичный UNIQUE INDEX или что-то ещё более "сильное" (PRIMARY KEY).