Horton

Fix missing EvalPlanQual recheck for TID scans

David G. Johnston <david.g.johnston@gmail.com>

View thread View on postgr.es
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Chao Li <li.evan.chao@gmail.com>
Cc: David Rowley <dgrowleyml@gmail.com>, Sophie Alpert <pg@sophiebits.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2025-09-15T06:04:52Z
Lists: pgsql-hackers 
On Sunday, September 14, 2025, Chao Li <li.evan.chao@gmail.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.

Commits

  1. Add missing EPQ recheck for TID Range Scan

  2. Add missing EPQ recheck for TID Scan

  3. Repair problems with EvalPlanQual where target table is scanned as

  4. Tid access method feature from Hiroshi Inoue, Inoue@tpf.co.jp