Всем привет - ребят не могу воспроизвести ситуацию с LOST

updates ни на каком уровне изоляции в PostgreSQL - скажите получается такую ситуацию нельзя наблюдать для PostgreSQL и именно поэтому в доке ничего про это не сказано?

Так а с чего ты взял, что LOST UPDATE возможен в PG? Его везде извели уже давно, на сколько я знаю, а был он лишь в InterBase

в PG update должен накладывать блокировку на изменяемые записи, так что lost update не будет возможен.

ок понял спасибо, странно что в доке упомянут только dirty read как тот феномен который не воспроизводится ни на каком уровне изоляции

Какой именно тип lost updates? Если то, что описывается в ISO SQL, то там ясно сказано "The four isolation levels guarantee that each SQL-transaction will be executed completely or not at all, and that no updates will be lost." Т.е. любую RDBMS, которая врёт утверждает, что она ACID, и допускает lost update на любом из стандартных уровней изоляции, можете смело выкинуть в окно. :) А под lost update в разных местах понимают следующее: 1. A lost update is considered to have taken place when data that has been updated by one transaction is overwritten by another transaction, BEFORE the first transaction is either committed or rolled back. 2. A lost update is when one transaction (Transaction #1) reads data into its local memory, and then another transaction (Transaction #2) changes this data and commits its change. After this, Transaction #1 updates the same data based on what it read into memory before Transaction #2 was executed. In this case, the update performed by Transaction #2 can be considered a lost update. ISO SQL запрещает именно и только первый.

LOST UPDATE (его феномена) на сколько я помню, нет в ANSI-стандарте, поэтому и нет (видимо) смысла об этом упоминать в документации.

Он там упомянут, и запрещается всегда, независимо от уровня изоляции. Так что про него ничего и не пишут, обычно...

Ну да,так и надо бы...

а 2 запрещен ANSI SQL?

Нет, написал же уже. ;)

Ну, как запрещён? Ты этого можешь добиться. Причём -- в любой СУБД

да я понял это не нарушение гарантий базы

однако в случае если поставить REPEATABLE READ - не будет воспроизводиться

будет

только что тестил - получил ERROR: could not serialize access due to concurrent update как и написано в доке

Ну значит pg это вообще явно ловит и не дает

Это в PostgreSQL, конкретно. Никто не запрещает другим СУБД вести себя иначе в отношении феноменов, не упомянутых в стандарте. Поэтому, IMNSHO, "заморачиваться" феноменами никакого смыла нет. Я к тому, что Вы либо используете SERIALIZABLE и Вам всё равно (никаких феноменов нет, независимо от реализации, если она корректная), либо Вам нужно знать механизмы реализации изоляции для используемых уровней изоляции в конкретной СУБД для того, чтобы написать надёжный код (и "феномены" Вам не помогут).