From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
Cc: | Sophie Alpert <pg(at)sophiebits(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Fix missing EvalPlanQual recheck for TID scans |
Date: | 2025-09-15 06:27:37 |
Message-ID: | CAKFQuwZt+RK4H01WK55ZHC37ZXwgD=s9FT8JgNes05pj7UcESw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sunday, September 14, 2025, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
> evantest=*# update t set b=30 where id = 1;
>
> evantest=*# update t set b = 30; # block here
> ```
>
> 1 | 5 | 30 <=== only the old tuple is updated
>
>
Can’t test right now myself but I believe you’ll find this much more
illustrative if you don’t have both S1 and S2 set the same column to the
same value when doing their updates. Also, include ctid in the select
outputs. If the second update would have been a=10 your final output
should be 1,10,30 - I.e. you’d find that both updates applied to id=1
after the second commit finished, and three tuples exist where id=1.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2025-09-15 06:27:59 | Re: Fix missing EvalPlanQual recheck for TID scans |
Previous Message | David G. Johnston | 2025-09-15 06:04:52 | Fix missing EvalPlanQual recheck for TID scans |