Роман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.Реализацию см. в исходниках.

qwwqимхо там тупое непонимание того, что на только читающей реплике в принципе не нужен сериалайзебл.У тебя тупое непонимание принципов изоляции в СУБД, и ничему учиться ты не хочешь. :(

qwwqили мастер уже отсериалайзил (в комиттеде -- очередями ) пишущие транзы и они в том же порядке накатятся. и никаких проблем в рипитебле на реплике не будет в принципе. или нет. реплика заведомо асинхронна, выше она не прыгнет. проблема надумана.Скажи мне, как мне удалось "надумать" thread в -hackers (причём, не один), где эта проблема обсуждается?

qwwqпонятно , что если логику раскатать тонким блинчиком по 100500 таблицам, а обновлять по 100 --50 , то любая попытка читать на реплике "как если бы транзакции были в затылок" сразу из всех 100500 таблиц нелогична. или жизнь параллельна, и некоторые события независимы -- и тогда снепшота на чтение достаточно. или сажать отдельного вертухая который бы всегда лочил всю базу под каждого отдельного писателя -- и тогда обреплицируйся как хошь. (и опять "сериалайзебл не нужен")Нормальным людям --- нужен, и у нас SERIALIZABLE просто работает , без вышеописанных "танцев".

qwwqдумаю, вертухаю непонятна сама идея параллельных независимых событий. что имитируя параллельные процессы с пересечениями из всех событий надо вычленить зависимые и разделяемые ими ресурсы, и только их то и выстроить в очереди. каждую очередь на своем ресурсе -- как точке пересечения. а в независимой области позволить событиям течь своим чередом.О да, каждый же должен вместо того, чтобы реализовывать нужную логику, заниматься "вычленением ресурсов" и "выстраиванием очередей".
Ты бы ещё на ассемблере предложил писать, самое ж время, в 21 веке.

Misha Tyurin http://www.slony.info/images/Slony-I-concept.pdf
не, ребят
(@PgSQLanonymous3, @Maxim Boguk, @qwwq),
там не про то.

Как Вам сказать... это была их цель (поэтому и concept), и они к ней пришли (возможно, даже и до 9.1, не интересовался).

Misha Tyurin> 2.4.1. Splitting the logdata
это к Serializable (SSI) никакого отношения не имеет.

Имеет, загляните в исходники. Дело в том, что log data --- это основа, на которой и строится вся эта репликация.
Поэтому, после сериализации этих данных, уже можно двигаться далее (передавать на подписчики и т.д. и т.п.).
(Впрочем, и какие-то "игры" со snapshots там тоже кое-где используются, но сути это менять не должно.)

Misha Tyurinменя сразу это смутило, так как slony-I -- это задолго до true ssi в pg
Ну так slony не стояли на месте всё это время, и все нововведения радостно используют (судя по исходникам). :)

Misha TyurinPgSQLanonymous3,
> Реализацию см. в исходниках.
> Ну так slony не стояли на месте всё это время, и все нововведения радостно используют (судя по исходникам). :)
пересмотрел слонов. ниче не нашел.
По слову "serializable" поищите.

Misha Tyurinremote_worker-тред просто применяет ивенты в порядке коммитов.
Только вот "достать" их с master он может не всякий раз, как мне помнится.

Misha Tyurinостальное там к делу не относится.Ну так воспроизведите какую-нибудь read-only аномалию (по отношению к master) на slave.
Если Вы правы, это должно быть просто. ;)