Re: Re: BUG #18750: Inappropriate update when it is blocked in RC

I'm so sorry that I forgot to provide you with the value of initial table t. The table is created as follows:
/* init */ CREATE TABLE t(a INT, b INT);
/* init */ INSERT INTO t VALUES (null, 1), (1, 1);

2024-12-24 20:37:10 "Pantelis Theodosiou" <ypercube(at)gmail(dot)com> 写道：

On Mon, Dec 23, 2024 at 12:57 PM PG Bug reporting form <noreply(at)postgresql(dot)org> wrote:

The following bug has been logged on the website:

Bug reference: 18750
Logged by: Yiran Shen
Email address: yrshen(at)stu(dot)xidian(dot)edu(dot)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.

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.