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

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.
>
>