Добрый день.

По этой ссылке описывается, каким образом PostgreSQL сериализует транзакции и от чего зависит результирующий порядок их выполнения:
https://wiki.postgresql.org/wiki/Serializable#Apparent_Serial_Order_of_Execution

Вопрос такой: А как этот порядок узнать? Например, для блокировочника я могу делать INSERT в таблицу c SEQUENCE в конце каждой транзакции и получить таблицу с этим порядком, что-то вроде:

Sequence_Num Описание транзакции1 внесение N руб на счёт A по документу B.2 снятие M руб со счёта A по документу C.



А как это сделать в PostgreSQL?

vyegorovВариант с последовательностями тут тоже подойдет, с оговоркой: т.к. нормальным поведением является откат транзакций из-за нарушения изоляции, то последовательность будет с “дырками”.

Можно смотреть в сторону системных колонок , xmin в частности. Но завязываться на них я бы не стал, все-таки это особенности физической реализации СУБД, могут измениться в будущем. Ну и ситуацию с wraparound'ом идентификаторов транзакций никто не отменял.

Также можно добавить поле `timestamptz NOT NULL DEFAULT clock_timestamp()` и сортировать по дате добавления записи в таблицу.

Я не понял, как это связано с порядком, в котором эти транзакции сериализованы? Меня же интересует именно он.

V&N

А это причём тут? Это явные блокировки, а меня интересует Serilalizable SSI без всяких hints, и мне нужно не заставить транзакции выполняться в каком-то порядке, а узнать , каким был порядок сериализации.

V&NЗачем?

Пока в основном теоретический интерес, мне просто непонятно, как это в принципе сделать. На практике может быть нужно для аудита, например.

V&Nи чем обычный SEQUENCE не подошел?
Очевидно, тем, что к порядку сериализации он отношения не имеет (или я чего-то не знаю). ;)

vyegorovПочему же не имеет? Значения будут отдаваться в порядке транзакций. Нумерация может прыгать, но порядок будет соответствовать.

Порядку их сериализации она может не соответствовать .

vyegorovВы бы попробовали что-нить протестировать, все сразу встанет на свои места.


А Вы бы попробовали по ссылке (на wiki) про это почитать, всё сразу встанет на свои места. ;)

V&N PgSQLanonymous , и чё, в блокировочнике SEQUENCE имеет какое-то отношение к уровню изоляции транзакции?

Нет, не имеет. SEQUNCE тут при том, что, при наличии конфликта, в блокировочнике последовательность COMMIT-ов совпадает с последовательностью сериализации.

V&Nмне вот сразу интересно стало, в каких случаях вы собираетесь использовать SERIALIZABLE
и чем не понравился repeatable read?

Во всех. Не понравился проблемами с консистентостью.

V&N № транзакции

И причём тут это? XID показывает, какая транзакция раньше началась физически , и всё.

Misha Tyurinсделайте единое узкое горло на какой нибудь блокировке. и под этой блокировкой уже крутите +1. это может быть блокировка таблицы, строки, или адвизори. или просто одна сессия -- однопоточная обработка.

Спасибо, но мне это не нужно, мне нужен ответ на мой вопрос. ;)

Misha TyurinМне кажется SERIALIZABLE вам и не нужен. какую задачу вы решаете изначально?


А мне вот кажется, тому, кому SERIALIZABLE не нужен, и с базами данных не стоило связываться, и что из того? ;)

Моя задача сформулирована в первом сообщении этой темы. ;)

Misha TyurinPgSQLanonymous,
вы не поверите, но "сериализация" внутри работает на блокировках. явного механизма "сортировки" "транзакций" нету.


Что Вы имеете в виду? Какие блокировки?

Конечно, явного механизма "сортировки" транзакций нет, но, т.к. они сериализованы, их можно расположить в какой-то последовательности, вопрос в том, как её выяснить (там, где это имеет значение, если транзакции не могли пересечься в принципе, их взаимная последовательность, конечно, значения не имеет).

Misha Tyurinгде узнать то? в какой момент?

Получить из базы каким-то образом. После COMMIT-а всех интересующих транзакций, например.

Misha TyurinМожет быть полезно такое правило: если мне чего-то не хватает, значит я не так взялся реализовывать свой велосипед. тогда надо описать велосипел сначала, скорее всего его уже 100500 раз делали. а вот потом уже, если вдруг, будем что-то новенькое городить

А разработчики PostgreSQL тоже что-то не так делают? ;)
Например, вот это связано с обсуждаемым вопросом:

http://www.postgresql.org/docs/9.4/static/hot-standby.html

The Serializable transaction isolation level is not yet available in hot standby. (See Section 13.2.3 and Section 13.4.1 for details.) An attempt to set a transaction to the serializable isolation level in hot standby mode will generate an error.

Misha Tyurinпредикатные в том числе

Да это понятно.

Misha TyurinPgSQLanonymous,

общий ответ на ваш топик -- никак
Вы уверены? Т.е. в блокировочнике тривиально, а здесь - никак?

Misha Tyurinугу, давайте удивите мир. ветка хакерс открытая, велкам

Мне лично hot standby пока настолько не нужен. ;)