| 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: | David Rowley <dgrowleyml(at)gmail(dot)com>, Sophie Alpert <pg(at)sophiebits(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Fix missing EvalPlanQual recheck for TID scans |
| Date: | 2025-09-15 06:04:52 |
| Message-ID: | CAKFQuwZjhJv_hRO=7V_6XhCQ-xD2ZuCL+4_giWNJAeNDhBd5AA@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:
>
>
> 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.
>
It will indeed see a future physical tuple so long as the logical row that
said tuple refers to already was committed, and it found the corresponding
past physical tuple.
Admittedly, I’m unclear on how exactly the system communicates/understands
that the past and future physical tuples refer to same logical row
reliably. In the docs, one is left to assume that feature just works.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2025-09-15 06:27:37 | Re: Fix missing EvalPlanQual recheck for TID scans |
| Previous Message | Naga Appani | 2025-09-15 05:47:41 | Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring |