In the test case for verifying the Lost Update (P4) anomaly, it is stated that at the "read committed" isolation level in PostgreSQL, this anomaly is not prevented:
Postgres "read committed" does not prevent Lost Update (P4)
However, in the repository’s README.md, there are several references to the definitions of isolation levels and anomalies.
Since the author notes that his work is based on the research by Peter Bailis et al., let’s refer to the paper mentioned in the second link:
Peter Bailis, Aaron Davidson, Alan Fekete, Ali Ghodsi, Joseph M Hellerstein and Ion Stoica:
“Highly Available Transactions: Virtues and Limitations (Extended Version),”
at 40th International Conference on Very Large Data Bases (VLDB), September 2014.
https://arxiv.org/pdf/1302.0309
The paper defines the Lost Update anomaly as follows:
In other words, an update made by T2 is considered lost if T1 performs its own update without rereading the current data before applying the change.
A check was performed according to the described procedure; however, the Lost Update anomaly was not observed (PostgreSQL 13.23):
show server_version_num ; -- PostgreSQL 13.23
server_version_num
--------------------
130023
(1 row)
-- DROP TABLE IF EXISTS lost_updates;
CREATE TABLE lost_updates (a integer);
INSERT INTO lost_updates(a) VALUES (1);
SELECT * FROM lost_updates;
a
---
1
(1 row)
-- lost updates
BEGIN; SET TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T1
BEGIN; SET TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T2
UPDATE lost_updates SET a = 2; -- T2
-- UPDATE 1 -- T2
UPDATE lost_updates SET a = a + 2; -- T1, BLOCKS
COMMIT; -- T2
-- UPDATE 1 -- T1
COMMIT; -- T1
SELECT * FROM lost_updates; -- T1
a
---
4
(1 row)
The second transaction does not lose the first transaction’s changes because, after releasing the lock, it rereads the row it attempts to update.
In the test case for verifying the
Lost Update (P4)anomaly, it is stated that at the "read committed" isolation level in PostgreSQL, this anomaly is not prevented:However, in the repository’s README.md, there are several references to the definitions of isolation levels and anomalies.
Since the author notes that his work is based on the research by Peter Bailis et al., let’s refer to the paper mentioned in the second link:
The paper defines the
Lost Updateanomaly as follows:In other words, an update made by T2 is considered lost if T1 performs its own update without rereading the current data before applying the change.
A check was performed according to the described procedure; however, the
Lost Updateanomaly was not observed (PostgreSQL 13.23):The second transaction does not lose the first transaction’s changes because, after releasing the lock, it rereads the row it attempts to update.