Dan Black
Ниже описывается прототип схемы хранения истории изменения объекта и проблема, которая скоро съест мой мозг
Хочется услышать мнения умных людей по поводу структуры хранения данных (таблиц и полей), и запросов к этим структурам. А так же варианты реализации задачи :)

...
Доп. условие задачи: Если внутри нашей транзакции у объекта изменилось значение, то при следующем вызове get_object_value должно???? возвратиться новое измененное значение. Изменения значения объекта в параллельных транзакциях не должны влиять на возврат функции get_object_value.

Пример.

внутри функции get_object_value делается простой запрос (к примеру)

внутри функции set_object_value так же делается запрос (к примеру)

Этих двух запросов хватает почти для всех случаев.
Вот один из случаев, для которых запросы не срабатывают
Есть огромное желание, чтобы при втором вызове get_object_value возвращалось то же значение, что и при первом вызове или измененное значение, но измененное в той же транзакции.
если действительно нужна исторя изменения величины, то "дополнительное условие задачи" этому просто противоречит.

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

Dan BlackГде-то так.
Ищу данные записанные в этой транзакции, если не нахожу, то смотрю данные записанные транзакциями завершившимися до начала текущей транзакции. Всё это решается установкой уровня транзакции Serializable, но такой возможности нет в силу других требований. Поэтому и ломаю голову, можно ли с использованием Read Committed, решить вопрос видимости данных (через запросы и структуры данных) аналогично действию уровня Serializable.вы наверное меня не поняли. Я рассказал, как получить искомое при Read Committed.

Ах да, я кажется понял . Вы о повторном чтении после только чтения , а не записи. Признаю невнимательность. Ну так сделайте ф-ю get пишущей . (можно даже не туда). (Вам же надо зафиксировать сам факт чтения).

прочел еще раз про кастом_вариации и массивы объектов и индексы... так вот, 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-тятся". Причем вы блокируете так все "объекты" _читаемые_ в транзакции?

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