Если из таблицы постгреса с колонками id, name, salary выполнить

в режиме REPEATABLE READ запрос select sum(salary) where name = "bob", то до завершения транзакции ведь должны забронироваться строки со всеми id у которых name= "bob"?

Нет, не должно

Чтобы заблокировать надо делать Select... For update...

похоже на то, действительно а на что тогда уровень REPEATABLE READ влияет? если его явно указать

Прочитайте лучше документацию (лучше всего — всю главу): https://www.postgresql.org/docs/current/mvcc.html

На изоляцию транзакций. Причём он же скорее всего и работает по умолчанию если ничего не указывал

так блокировка строк о которой я спрашивал - и есть изоляция (способ её достижения)

Безусловно. Но средство и еë цель это не одно и то же

ну в чем это выражается тогда? если не в том что я написал в изначальном вопросе

Вот начальный вопрос. Что тут выражается?

там предполагается а тут в чём выражается эта изоляция?

А читать документацию Вы принципиально отказываетесь или как (описания лучше, чем там, Вы нигде не найдёте)? Может, Вы ожидаете, что кто-то сюда процитирует весь соответствующий раздел? ;)

наверное, раз сюда пришёл, то прочитал её и не пары моментов:) что и принёс

> на что тогда уровень REPEATABLE READ влияет? Таки придётся цитировать, да? ;) Влияние (отличие от RC) номер раз: The Repeatable Read isolation level only sees data committed before the transaction began; it never sees either uncommitted data or changes committed during transaction execution by concurrent transactions. This level is different from Read Committed in that a query in a repeatable read transaction sees a snapshot as of the start of the first non-transaction-control statement in the transaction, not as of the start of the current statement within the transaction. Thus, successive SELECT commands within a single transaction see the same data, i.e., they do not see changes made by other transactions that committed after their own transaction started. Влияние (отличие от RC) номер два: Applications using this level must be prepared to retry transactions due to serialization failures. UPDATE, DELETE, MERGE, SELECT FOR UPDATE, and SELECT FOR SHARE commands behave the same as SELECT in terms of searching for target rows: they will only find target rows that were committed as of the transaction start time. However, such a target row might have already been updated (or deleted or locked) by another concurrent transaction by the time it is found. In this case, the repeatable read transaction will wait for the first updating transaction to commit or roll back (if it is still in progress). If the first updater rolls back, then its effects are negated and the repeatable read transaction can proceed with updating the originally found row. But if the first updater commits (and actually updated or deleted the row, not just locked it) then the repeatable read transaction will be rolled back with the message ERROR: could not serialize access due to concurrent update because a repeatable read transaction cannot modify or lock rows changed by other transactions after the repeatable read transaction began. Что тут конкретно непонятно?

Спасибо, друг...

читал их. и оба они не объясняют то, почему строки после первого удачного SELECT-а не блочатся, а противоречат

Я не понимаю, что Вы пишете. :( В PostgreSQL (речь только об обычных DML — INSERT/UPDATE/DELETE) писатели никогда не блокируют читателей, а читатели никогда не блокируют писателей. Никаких "настоящих" (которые могут привести к блокировкам) locks при чтении ни на одном уровне изоляции PostgreSQL не накладывает. > а противоречат Чему это они "противоречат", как Вам удалось так прочитать процитированное?!

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

> внимательно прочитал. а вы? Прочитали что именно? > то второй селект должен получить ошибку Ничего подобного. Опять-таки, как из написанного @MasterZiv правильного ответа Вам удалось сделать противоположный вывод?!

вывод сделан на основе второго отличия из вашей цитаты доки

Опять-таки, это Вам как удалось? ;) Там написано про конфликт писателей... послушайте, есть же перевод этой документации (не знаю, правда, насколько качественный) — может, там Вам будет понятнее? https://postgrespro.ru/docs/enterprise/15/transaction-iso#XACT-REPEATABLE-READ

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

> просто я предполагал уровень REPEATABLE read предполагает констистентность всех селектов Эээ... что вообще такое "констистентность"?! Если Вы думаете, что у этого понятия есть однозначное общепринятое определение, то зря. ;( Если Вы имеете в виду "Repeatable Read isolation level only sees data committed before the transaction began" — то да, так оно и есть, документация не врёт. > а для этого апдейту, сующемуся между ними придётся подождать Разумеется, нет. "Писатели никогда не блокируют читателей, а читатели никогда не блокируют писателей" справедливо всегда — это не преувеличение, а твёрдый принцип (гарантия) в PostgreSQL. Как мне ещё это написать? ;) Вот оно же из документации: "The main advantage of using the MVCC model of concurrency control rather than locking is that in MVCC locks acquired for querying (reading) data do not conflict with locks acquired for writing data, and so reading never blocks writing and writing never blocks reading. PostgreSQL maintains this guarantee even when providing the strictest level of transaction isolation through the use of an innovative Serializable Snapshot Isolation (SSI) level."