> Если Вы имеете в виду "Repeatable Read isolation level

only sees data committed before the transaction began" — то да, так оно и есть, документация не врёт.

получается, что в запросе с режимом REPEATABLE read который я привел происходит неповторяющееся чтение

вы так восклицаете с самого первого раза, хотя восклицать нужно мне:)
(с того что вы с которого раза не можете понять примитивнейий конфликт в голове погружающегося в этот топик: уровень rr, при этом эффект non-rr. как так?)

тут уже я не знаю как перефразировать один и тот же вопрос в очередной раз

> что в запросе с режимом REPEATABLE read который я привел происходит неповторяющееся чтение Нет, не получается. Вы сами это видели? Разумеется, нет — потому что это было бы ошибкой. > вы так восклицаете с самого первого раза, хотя восклицать нужно мне:) Потому что Вы всё понимаете превратно. :( Более того, документация PostgreSQL именно про concurrency control — это лучшее, что Вы найдёте в интернете (даже по сравнению с "классическими" учебниками, поверьте — я читал несколько). Как так выходит, что из неё Вы делаете такие выводы, меня откровенно изумляет. > уровень rr, при этом эффект non-rr. Там. Нет. Этого. Эффекта. Приведите-ка определение non-repeatable read, раз Вы такое утверждаете. > тут уже я не знаю как перефразировать один и тот же вопрос в очередной раз Ваш вопрос основан на ложной посылке — что толку его перефразировать?

У нас обе версии хранятся — и до обновления (которая видна ранее начатой транзакцыи-читателю) и обновлённая (которая ей невидна). Потому он и мульт-версион конкурренси контрол. (Ярослав, подозреваю, хотел, чтобы вы сами нашли эту информацыю, ориентируясь на выводы из противоречий, возникающих с вашэй ментальной модэлью — но, кажэтся, он слишком многого хотел).

первый вопрос был "блокирует"? коллега отвечает "нет"

и я всё-таки не понимаю почему два селекта выдают разную инфу при rr, если влезает промежуточная транзакция (обновляющая)

В одной транзакции иди в разных?

Потому, что могут! (Действительно, нафига бы транзакцыи, начавшэй читать данные после коммита — не видеть результатов этого коммита).

И отвечает совершенно верно! Что Вам в этом непонятно?

Вам уже (трижды?) написали, что нет, не выдают! Вы способны хотя бы это осознать, или > если Ярославу нравится терять время, что ж, его право мне стоит прекратить? ;)

1 транзакция селект sum(*) 2 транзакция update 1 транзакция снова селект sum(*) написал в хронологическом порядке 😭

Результаты первого и второго SUM() в (открытой, продолжающейся) транзакции 1 с уровнем изоляции RR в PostgreSQL всегда (если она сама не меняла эти данные) будут одинаковыми. Обратите внимание, что по ISO SQL это не обязано быть так.

ок спасибо надо в след раз просто запускать на базе игрушечной...

Тогда оба результата sum будут одинаковые.

получается, при описанном мной сценарий читающая транзакция при втором sum(*) получит (вот тут уже термин точно подходит) неконсистентные данные (с реальной базой, но констстентные между собой)? раз между двумя чтениями эти строки обновит конкурентная транзакция

> вот тут уже термин точно подходит Нет. Более того, сам вопрос полностью выдаёт, что у Вас нет "фундамента" для понимания изоляции (Вы не знаете, что такое Isolation из ACID), извините. :( Я ещё раз советую Вам прочитать всю ту главу из документации PostgreSQL (и читать до тех пор, пока не наступит понимание, что в реальности "консистентность" обратна тому, что Вы подразумевали в своём вопросе). Или почитайте какой-то учебник (но, опять-таки, мне кажется, что многие из них как минимум не лучше).

Ну так и есть а как ты предлагаешь чтобы работала система управления базами данных? Это и Логично, транзакция один раз прочитала данные получила их, дальше хочет ещё раз прочитать эти данные что она должна получить? Она должна получить то же самое, те же данные, что прочитала в первый раз, этого и есть и изоляция транзакций. Вот если транзакция один завершилось бы и потом началась бы транзакция три которая читала эти же данные ну эти же логические данные Но следующий транзакции тогда она бы видела транзакция два

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

Точно... Гетто для особо умных

нет, я согласен не говорю что это неправильно просто подмечаю, что если бы tx1 брала лок, то tx2 бы пришлось подождать первую, и тогда первая бы читала реальные данные во всей базе, а не лишь своём снимке

Так и происходит в так называемых "блокировачниках" - СУБД типа SQLServer

а в mvcc-based последующие чтения актуальны лишь в рамках снимка. и это тем не менее считается RR для них