| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | Sophie Alpert <pg(at)sophiebits(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Fix missing EvalPlanQual recheck for TID scans |
| Date: | 2025-09-15 06:27:59 |
| Message-ID: | CAApHDvqNH8AObaQh6PrDq_-X7Zg5G6hN4GeB7DYw84z3bc7kKg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 15 Sept 2025 at 17:32, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> UPDATE, DELETE, SELECT FOR UPDATE, and SELECT FOR SHARE commands behave the same as SELECT in terms of searching for target rows: they will only find target rows that were committed as of the command start time.
>
> It says that UPDATE will only find target rows that were committed as of the command start time. I think the statement implies that an “update” statement will never update a “future” tuple.
I think you've only read the first sentence in that paragraph. Please
read the entire paragraph. You'll see it goes on to explain "it will
attempt to apply its operation to the updated version of the row".
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2025-09-15 06:35:00 | Re: [PATCH] jit: fix build with LLVM-21 |
| Previous Message | David G. Johnston | 2025-09-15 06:27:37 | Re: Fix missing EvalPlanQual recheck for TID scans |