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.
Если Вы правы, это должно быть просто. ;)