Добрый день.

По этой ссылке описывается, каким образом 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 пока настолько не нужен. ;)

V&Nприступайте к работе, вы уже определились. и ни в коем случае не понижайте уровень транзакции. SERIALIZABLE - и всё.
А почему бы и нет? Из-за иррациональной боязни низкой производительности? ;)

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

В MS SQL тоже нет, например.

Misha TyurinВ случае SERIALIZABLE в общем виде они могут идти параллельно, так как могут не разделять ничего общего.

Ну да, я про это уже писал.

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

Незачем, мне хотелось бы узнать эту последовательность, не изменяя её.

Misha TyurinУ вас, в блокировочнике, почти уверен, изменение сиквенса лочит всё на нём. -- это и есть явный лок
Нет, не лочит. В блокировочнике это работает за счёт того, что последовательность сериализации совпадает с последовательностью COMMIT-ов. Т.е. первым значение получит тот, кто блокирует (и тут же сделает COMMIT), а затем уже тот, кого он блокировал.

ЁшОна же очевидно будет ниже, придётся некоторые транзакции по несколько раз повторять из-за конфликтов сериализации.
Безусловно, будет! Так давайте всё на ассемблере писать! ;)

Даёшь READ UNCOMMITTED - главное считать быстро , результат не имеет значения! ;)

Если серьёзно, вопрос тут в том, будет ли производительность неприемлемо низкой, и стоит ли повышение производительности отсуствия гарантии консистентности.

Misha Tyurinкого блокирует то?

Другую транзакцию на том ресурсе, за который они конкурируют, конечно.

Misha Tyurinо какой консистентности речь?
вы можете хоть как-то её, хоть на пальцах описать?
О той, которая гарантируется SERIAIZABLE. Я не понимаю, зачем её описывать "на пальцах", когда в стандарте SQL чётко сказано, что это такое.

Misha Tyurinобновление счетов, делается консистентно между конкурируюшими трназкциями в режиме ридкоммитед, как раз за счет блокировок счетов/аккаунтов

Или не делается, от ситуации и метода изоляции зависит. Вы о каком READ COMMITTED говорите (версионный или блокировочный) и о какой ситуации? И, кстати, обновление счетов я привёл просто как пример, вопрос был общий.

Гость_0Не существует СУБД полностью поддерживающей стандарт, хотя бы по этому.

Ну и что? В части обеспечения изоляции существует немало СУБД, полностью поддерживающих стандарт, и PostgreSQL - одна из них.

Misha Tyurinчет у вас всё путается.

Почему это - у меня? ;)

Misha Tyurinкогда я говорю о уровне изоляции, я как раз имею ввиду sql и феномены, и я не вижу разницы в движке базы: версионник или блокировончик, -- это уже ваще не важно.

Как это неважно? В PostgreSQL на REPEATABLE READ ни одного из описанных в стандарте феноменов нет вообще, а в блокировочнике есть фантомы, и т.д.

Misha Tyurinв сиквелсервере, сиквенс генерится в момент коммита. это ваще к уровням изоляции уже имеет отдаленное отношение, так как это всё вне транзакции. подозреваю, что есть лок на фиксацию транзакции в журнал, вот там вы и лочитетсь. лок есть, но не явный опять.

Ещё раз - нет там никакого лока, и SEQUENCE я могу использовать как часть метода отслеживания порядка сериализации.

Misha Tyurin // лично не видел, нагуглил: http://msdn.microsoft.com/ru-ru/library/ff878091.aspx "Порядковые номера создаются вне области текущей транзакции. Они обрабатываются, когда выполняется фиксация или откат транзакции, использующей порядковый номер."

Просто неправильный перевод. Там написано вот что:

Sequence numbers are generated outside the scope of the current transaction. They are consumed whether the transaction using the sequence number is committed or rolled back.

То есть это внетранзакционный, неблокирующий механизм.

Misha Tyurinпо sql стандарту, кстати, постгресовый рипитаблрид как раз есть сикуель-сериалайзебл.

Ничего подобного! Всё это чётко описано как в стандарте, так и в документации:
http://www.postgresql.org/docs/9.4/static/transaction-iso.html

Misha Tyurinвы точно уверены какой уровень именно вам нужен и зачем. каких случаев вы хотите избежать?

Да, уверен. Я хочу избежать всех случаев, не разбираясь с ними. ;)
Цитата из той же ссылки:

Consistent use of Serializable transactions can simplify development. The guarantee that any set of concurrent serializable transactions will have the same effect as if they were run one at a time means that if you can demonstrate that a single transaction, as written, will do the right thing when run by itself, you can have confidence that it will do the right thing in any mix of serializable transactions, even without any information about what those other transactions might do.


Misha Tyurinсмотрите еще какой момент. если транзакции шли как (1,2,3), а потом мы их видим как (2,1,3), но при этом результат последовательного применения по обоим порядкам одинаков, то обо порядка удовлетворяют условию сериализации. вам какой из порядков надо?

Любой.

Misha Tyurinеще раз обращаю внимание! в вашем блокировочнике (почти наверняка) есть *лок* на сиквенсе! -- но он не на уровне транзакций, а в движке фиксации коммита.

Ещё раз обращаю Ваше внимание, что лока там нет .


Misha Tyurin2) либо (не явные локи) ВСЁ надо по дефолту в сериалайзебл, все совсем транзакции сериалайзебл и только такие.

но и во втором случае вы НЕ получите порядок физических коммитов, а получите лишь один из "последовательных порядков".

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

Гость_0PgSQLanonymous, ну вообще то нет, read uncommitted в postgres нет. Не хотите объяснять - ваше дело, что мне вас заставлять что ли?

Ну вообще-то да, и READ UNCOMMITTED в PostgreSQL формально есть. Вот цитата из документации, кстати (выделение моё):

When you select the level Read Uncommitted you really get Read Committed, and phantom reads are not possible in the PostgreSQL implementation of Repeatable Read, so the actual isolation level might be stricter than what you select. This is permitted by the SQL standard: the four isolation levels only define which phenomena must not happen, they do not define which phenomena must happen.

думаеццакакбе праткически то, что миша привел в кач-ве перевода

Как бы нет.
They are consumed whether the transaction using the sequence number is committed or rolled back.


Перевод примерно такой:

Они потребляются (используются) независимо от того, выполнена ли фиксация или откат транзакции, использующей порядковый номер.

думаеццаоткуда взялось словцо "неблокирующий"

Это следует из документации MS SQL, например.

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

А ты не хамить не можешь?

думаеццаИтак -- русурс -- присвоитель номера-- один, не бесконечно быстрый (по определению)
пользователей -- много (транзакции)
а где они толкаются -- прямо перед ресурсом, или в кордорчике доступа к оному [или даже реально на однем камешке в затылочек друг-друго ходят, изображая параллельность] -- дело десятое, главное что такое место есть. его не может не быть.

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

думаеццавам нужно переписать коммит пж так, чтобы он тоже совался к каокому-нито "неблокирующему" [т.е. короткоблокирующему-- на время доступа] ресурсу. и писал его значение кудыньть в.
начать и кончить

Нет, это не поможет, сколько можно повторять? В SSI последовательность сериализации не совпадает с последовательностью COMMIT-ов.

думаеццакстати, что txid относится к началу а не к концу, не имеет в случае честного бетонного и именно сериалайзебла никакой роли.
опять же если порядок требуется любой из возможных.
или я вру ?
ведь если вона коничла, то другие, позже стартовавшие, явно ей не помешали кончить.
и могут щитаццо более позжими.
( и если кончили, и если обломались)
и так -- с каждой парой */автор интересуется только конившими/
т.е. попарные сравнения заданы, и заданы непротиворечиво, аддитивно и перестановочно
нет ?
Нет. Прочитай раздел "Apparent Serial Order of Execution" по ссылке из первого сообщения темы.

anonymous anonymous а я маленькину какбе читателю анкомиттед интересна не буква стандарта, а что другие негодяи в запись-пись успели понаписать.
Пусть найдёт себе другой глобус, я считаю. ;)

anonymous anonymous а я маленькии пж--негодяи вполне могли бы такое под своей какоё-нить уровнёй реализнуть. если им шапка из стандарта не по нутру. поленились, ссуки
т.ч. комитеты такие комитеты

Они как-то это обсуждали, вот, например, мнение Tom Lane по этому поводу:
http://www.postgresql.org/message-id/5209.1211760608@sss.pgh.pa.us]http://www.postgresql.org/message-id/5209.1211760608@sss.pgh.pa.us

Или вот ещё: http://www.postgresql.org/message-id/AANLkTikLBFk4mE=fg18wLStLPwGJTEbOhS=sY5G9smgQ@mail.gmail.com]http://www.postgresql.org/message-id/AANLkTikLBFk4mE=fg18wLStLPwGJTEbOhS=sY5G9smgQ@mail.gmail.com

думаеццану если у вас проблемы с русски, и "или"[-или] в качестве либо-либо вас не устраивает, -- можешьте педалировать "независимость", педалик вы нашЪ

Понятно, не хамить не можешь. :( И полезного ничего не говоришь.
Наше общение, я, пожалуй, закончу на этом:

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


Оригинал:
They are consumed whether the transaction using the sequence number is committed or rolled back.

Перевод 1:
Они обрабатываются, когда выполняется фиксация или откат транзакции, использующей порядковый номер.

Перевод 2:
Они потребляются (используются) независимо от того, выполнена ли фиксация или откат транзакции, использующей порядковый номер.

Разница очевидна, IMHO.