Note: Tx1 means transaction 1 and Tx2 means transaciton 2. The bug case for the concurrent transactions is executed in the following order. How to repeat： ----------------------------------------------------------------------------- /* Tx1 */ BEGIN; /* Tx1 */ SET TRANSACTION ISOLATION LEVEL READ COMMITTED; /* Tx2 */ BEGIN; /* Tx2 */ SET TRANSACTION ISOLATION LEVEL READ COMMITTED; /* Tx1 */ UPDATE t SET b=3; /* Tx2 */ UPDATE t SET b=2 WHERE a IS NOT NULL; /* Tx1 */ UPDATE t SET a=1; /* Tx1 */ COMMIT; /* Tx2 */ COMMIT;
/* Tx1 */ SELECT * FROM t; -- actual: [(1, 3), (1 ,2)], expected: [(1, 2), (1, 2)] ----------------------------------------------------------------------------- The UPDATE statement of Tx2 was initially blocked by the first UPDATE statement of Tx1. It recovered after Tx1's COMMIT, but its query result is incorrect. According to the documentation of PostgreSQL 17, the Transaction Isolation of the section 13.2 has denoted that the UPDATE statement of Tx2 should attempt to apply its operation to the updated version of the row in RC if the first updater commits.
You haven't shown us the existing values in the table, before the transactions started. Was column a, NULL for one row and NOT NULL for the other row?
So I'm wondering if this is a bug in RC that doesn't meet that isolation level.
