прочел еще раз про кастом_вариации и массивы объектов и индексы... так вот, temp таблицы вполне индексируемы.
создаете temp таблицу (со всеми нужными индексами) первым get/set-ом. И хороши они тем, что их вакуумить не надо. Т.е. для фиксации фактов единичной транзакции, причем массовых фактов, с индексными поисками - они - самое то.

Dan Blackпридётся смириться с фактом, что эмуляция Serializable будет не полная, но и то хлеб :)да, из этой эмуляции выпадает всё то, что произвело изменения _до_ начала текущей транзакции, но было закоммиченно _после_ ее начала, причем _до_ первого опроса текущей транзакцией данного исторического значения. Для закрытия этой дыры надо писать еще куда-то и моменты окончания транзакций . Что, как мне видится, довольно сложно. При этом, даже если мы запишем эти данные, получить неизменные данные можно будет только в таблице историй (отсекая поздние). Если же в базе есть не только логгируемые данные - их состояние на момент старта получить уже будет нельзя. (т.е. тогда от честного сериалайзбл не уйти).


Может быть записывать в начале транзакции во времянку id-ки всех запущенных транзакций? (покурочить на эту тему pg_stat_activity). И считать "временем старта" нашей тр-ии время этого стартового опроса ид транзакций. Но потребуется четкое требование любую транзакцию начинать с такой записи ид-ков всех незавершенных тр-й.

Dan Black Объясните, где я потеряю данные? наверное имелось в виду, что если у вас все данные - именно таким вот образом "логированные "версии", то у вас нет механизма разрешения (да и самого возникновения ) коллизий. Т.е. у вас как-бы параллельно может существовать несколько исторических нитей (цепочек транзакций) изменения данных, ничего не знающие друг о друге кроме исходной точки (момента запуска первых транзакций этих параллельных цепочек). Поскольку "апдейт", вызывающий в нормальной ситуации блокировку изменяемой записи до конца транзакции у вас заменен на инсерт. А он, инсерт, ничего не блокирует (только не отдает свою запись другим транзакциям до коммита, т.ч. другие транзы спокойно пользуют "параллельные версии"). Коллизий напрочь не возникает (т.е. ситуация не то что не эмулирует сериалайзебл, но много хуже Read Commited). Возникают самостоятельные ветки в истории, обрываемые (теряющие значение) коммитом последней "параллельной" транзакции. Если же механизм логгирования дублируется еще и апдейтом в "обычной" таблице - то в зависимости от существования в схеме в т.ч. "нелоггируемых" - т.е. "обычных данных" (поставляющих вам блокировки апдейтуемых транзакциями величин для поддержания логической связности обновлений), или даже при логгировании всех - от порядка опроса данных в процессе разных транзакций вы будете иметь дырки в имитации сериалайзебл режима с точностью до разрыва в порядках опроса "объектов".

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

Dan Black 4321Да. Что мне в итоге надо, я получу :) Механизм решения конфликтов есть и работает. если расскажете о механизме генерации и разрешения конфликтов в вашей схеме исторических данных - то это будет интересно. Пока же я вижу, что никаких "конфликтов" у вас возникать не будет, а будут возникать параллельно-независимые "кучи мусора", перекатываемые в параллельных цепочках транзакций и уносимые периодически вникуда. (там что-то типа механизма согласования мультимастер реплик просится - на каждый коммит транзакции)
Dan Black(Конфликты - это результат работы процедуры, меня же интересовало как получить "правильные" исходные данные для обработки)конфликты логики - это то, что куча транзакций будет возиться с неактуальными ветками "истории" данных, так и не пошедшими в итоге в дело. Кто у вас, кроме механической очередности стартов, будет определять, какая куча транзакций дожна пойти в такой-вот мусор? а конфликтов-то при этом между транзакциями (из-за блокировки) и не возникнет.

Dan BlackПроблема параллельных историй не существует, так как если такое обнаруживается, то происходит либо полный откат транзакции с выдачей ошибки, либо повторный перезапуск транзакции :)ну вот как раз и интересно, зачем вам руками создавать такие же проблемы, что вам создает простой "честный сериалайзебл". Или вы думаете, что рукотворный будет чуть быстрее? Кстати, а как вы проверяете "параллельность" историй данного? Это ведь, пожалуй, самое интересное.


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

ПС ах, да я забыл случай, когда величины принимают значения из очень небольшого набора (скажем всего из 2-х значений) . Тогда даже если к моменту завершения транзакции было прокммичено множество параллельных историй, тем не менее вероятность того, что в истории "поучаствовало" правильное данное будет около 1/2. Правда если в транзакции попользовались N данными, и все они меняются независимо, то вероятность придти к такому же состоянию истории, как на момент старта транзакции становится (1/2)**N т.е. уже при N>~3 на такое "улучшение" можно честно плевать.

Dan Black 4321Обход "честного serializable" и проверка на параллельное измение истории происходит с помощью оптимистической блокировки объекта, с историей изменения которого работает процедура. Получается практически полная эмуляция транзакции Serializable.
- т.е. у вас кроме таблицы историй , есть еще собственно "объекты" (таблица собственно объектов), которые, скажем, что-то типа "SELECT FOR UPDATE-тятся". Причем вы блокируете так все "объекты" _читаемые_ в транзакции?

Или я опять что-то не так понял?