Re: Fix missing EvalPlanQual recheck for TID scans - Mailing list pgsql-hackers

From Sophie Alpert
Subject Re: Fix missing EvalPlanQual recheck for TID scans
Date
Msg-id c536bcf7-8cee-4fc1-8ed8-69408da88f7d@app.fastmail.com
Whole thread Raw
In response to Re: Fix missing EvalPlanQual recheck for TID scans  ("Sophie Alpert" <pg@sophiebits.com>)
List pgsql-hackers
On Sat, Sep 13, 2025 at  3:12 PM, Sophie Alpert <pg@sophiebits.com> wrote:
> And indeed, like I mentioned in my previous message, my isolation test 
> `permutation tid1 tidsucceed2 c1 c2 read` from eval-plan-qual.spec in 
> my patch will fail if Recheck were to return false in this case. Though 
> somewhat contrived, you can imagine this happening with multiple 
> sessions driven by the same application:

Another case where returning FALSE does not give the correct behavior is when two relations are involved, only one of
whichis modified:
 

S1: BEGIN;
S2: BEGIN;
S1: UPDATE accounts SET balance = balance + 100 WHERE ctid = '(0,1)' RETURNING accountid, balance;
S2: SELECT * FROM accounts JOIN accounts_ext USING (accountid) WHERE accounts_ext.ctid = '(0,1)' FOR UPDATE OF
accounts;
S1: COMMIT;
S2: COMMIT;

In my patch the S2 query correctly returns one row, whereas with your proposed change it incorrectly returns none.

accountid|balance|balance2|balance|other|newcol|newcol2
---------+-------+--------+-------+-----+------+-------
checking |    700|    1400|    600|other|    42|       

Sophie



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Adding skip scan (including MDAM style range skip scan) to nbtree
Next
From: Thomas Munro
Date:
Subject: Re: meson's in-tree libpq header search order vs -Dextra_include_dirs