The following bug has been logged on the website:
Bug reference: 18750
Logged by: Yiran Shen
Email address: yrshen@stu.xidian.edu.cn
PostgreSQL version: 17.2
Operating system: Ubuntu 22.04
Description:
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. So I'm wondering if this is a bug in RC
that doesn't meet that isolation level.
