On Thu, Jun 24, 2021 at 5:39 AM Simon Riggs <simon.ri...@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
