Роман87Задача стоит в настройке частичной репликации (нужны таблицы только для отчетов) master-slave
С физическим hot standby частичной репликации не получится, только весь кластер.

Vadim LejninРоман87,
Как Вариант,
У Вас же read-only? Создайте физический stream standby, и отказоустоячивость, и отчеты
Строго говоря, для отчётов это "осетрина второй свежести", т.е. в отчётах вы изредка можете получать неконсистентные данные (но многие на это забивают).

Роман87Maxim Boguk, спасибо за ответ!
Обсудили, решили продолжать идти по пути PGLOGICAL, из-за того, что хотят на slave создать дополнительную бизнес логику рассчитанную на основе частично реплицированных данных.
Кстати, у логической репликации (в отличие от, например, slony) ровно та же проблема (просто предупреждаю):
Строго говоря, для отчётов это "осетрина второй свежести", т.е. в отчётах вы изредка можете получать неконсистентные данные (но многие на это забивают).

qwwqв каком именно смысле неконсистентность.
в смысле асинхронности ? (не соотв текущему сост. мастера ?)

Конечно, нет (и так очевидно, что асинхронный standby может отставать, физический он или логический).

qwwqили в смысле неконсистентности И на прошлый момент времени (неконсистентные снапшоты) ?

Да, именно в этом смысле.
Кстати, с каких пор адептов READ COMMITTED-only изоляции это вообще волнует? ;)
Я имею в виду только full-ACID (SERIALIZABLE).

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

Да, только вот "рекавери" подразумевает, что какие-то транзакции могут быть потеряны (и до консистентности read-only ему вообще дела нет).

qwwqили там наколхозили тоже ?

Там как раз "недоколхозили". ;)

qwwqи чо, у логики те же проблемы что у потоковой ?

Разумеется.

qwwqмеханизм на пальцах покажите, если просекли. а то блабла кокойто.
Механизмы "на пальцах" показаны в https://wiki.postgresql.org/wiki/SSI#Read_Only_Transactions
Всё это легко происходит на standby / logical replication. В документации:

https://www.postgresql.org/docs/current/static/hot-standby.html#HOT-STANDBY-CAVEATS (последний пункт).
https://www.postgresql.org/docs/current/static/applevel-consistency.html#SERIALIZABLE-CONSISTENCY (warning).

Maxim Boguk1)На фига на readonly реплике serizaliable? Откуда там вы запись будете брать и как делать? Объясните???

То есть ссылку Вы не открыли, и ни о чём не подумали? Не стыдно? Мне ссылку ещё раз дать?

Maxim Boguk2)Один отдельный запрос всегда и так работает в repeatable read так что аномалий чтения та быть не может если отчет 1 запросом строится (причем что на реплике что на мастере)

Да вы что? А я-то думаю, кто же это этот snake oil "repeatable read так что аномалий чтения та быть не может" продаёт из консультантов? Теперь буду знать (шутка).

Maxim Boguk3)Для readonly отчетов прекрасно хватает repeatable read уровня изоляции, и если там в отчете много запросов... а repeatable read прекрасно на hot standby реплике работает (там то локов никаких не надо просто snapshot в начале транзакции зафиксировать).

Maxim, вам действительно стоит почитать... да, на первый взгляд read-only anomaly поражают... но они от этого из реальности никуда не исчезают, увы.
Вот ещё, кстати: https://www.postgresql.org/message-id/flat/CAEepm%3D2b9TV%2BvJ4UeSBixDrW7VUiTjxPwWq8K3QwFSWx0pTXHQ%40mail.gmail.com#CAEepm=2b9TV+vJ4UeSBixDrW7VUiTjxPwWq8K3QwFSWx0pTXHQ@mail.gmail.com]https://www.postgresql.org/message-id/flat/CAEepm=2b9TV vJ4UeSBixDrW7VUiTjxPwWq8K3QwFSWx0pTXHQ@mail.gmail.com#CAEepm=2b9TV vJ4UeSBixDrW7VUiTjxPwWq8K3QwFSWx0pTXHQ@mail.gmail.com

Maxim BogukPS: на логической реплике кстати serializable прекрасно будет работать просто по своей природе.

Будет-будет, вот только формально. Т.е. read anomaly (по сравнению с master) вы всё равно увидите.

qwwqт.е. сам не воткнул , двумя словами описать не можешьте , а туда же -- пальцы гнуть.
низачот, стьюдент
Who are you to fucking lecture me?
Не умеешь читать / слишком тупой, чтобы понять? Это твои проблемы.

Maxim BogukЕсли рассматривать как раз readonly пример то для реплики проигрывающей WAL файл сначала пришла
T2 которая выглядела как update rollover set n = 11 where id = 2;
после чего пришла
T1 вида update rollover set n = 110 where id = 2;
Никакой информации о том что T1 строился исходя из данных которые менялись в T2 - у реплики нет.
Да, именно так.

Maxim BogukПока информация о SSI по WAL потоку не передается -требовать чтобы подобных аномалий не могло на асинхронной реплике возникать - глупо, это невозможно физически.Вот об этом-то "невозможно" я и предупредил, всего лишь.

Maxim BogukПередавать всю SSI кухню в WAL - сделать SSI еще более медленным чем он сейчас есть (причем принципиально более медленным).А всю и не нужно, есть другое решение --- поддерживать только DEFERRABLE (см. thread, на который я уже ссылался).

Maxim BogukPS: а почему вы считаете что у Slony нет такой проблемы? Там по моему ровно тоже самое будет.
А именно сначала слонами приедет update rollover set n = 11 where id = 2; а потом слонами отдельной тоже операцией приедет update rollover set n = 110 where id = 2;Потому что в slony об этом подумали, и реализовали:
Slony-I will split the entire amount of replication activity into smaller units covering a few seconds of workload as described in section ...
This will be done on the visibility boundaries of two serializable transactions.
So the slave systems will leap from one consistent state to another as if multiple master transactions would have been done at once.Реализацию см. в исходниках.