On Thu, Jun 24, 2021 at 5:39 AM Simon Riggs
<simon.riggs@enterprisedb.com> wrote:
> This case occurs when we are doing non-HOT UPDATEs. That command is
> searched, so the scan will already have touched the heap and almost
> certainly the index also, setting any LP_DEAD bits already in the most
> frequent case.
But it won't, because the restriction that I described with non-HOT
updates in kill_prior_tuple in that old thread I linked to. This has
been the case since commit 2ed5b87f96d from Postgres 9.5. This
probably should probably be fixed, somehow, but for now I don't think
you can assume anything about LP_DEAD bits being set -- they're
clearly not set with a non-HOT update when the UPDATE's ModifyTable
node is fed by a scan of the same index (unless we reach
_bt_check_unique() because it's a unique index).
--
Peter Geoghegan