On Wed, Jun 23, 2021 at 5:42 PM Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Wed, Jun 23, 2021 at 9:31 AM Simon Riggs
> <simon.riggs@enterprisedb.com> wrote:
> > You're right that skipping the check might also skip killing a prior
> > row version, but it doesn't prevent later scans from killing them, so
> > there is no correctness aspect to that.
>
> Probably not, no. I'll assume for now that there is no correctness issue.
>
> > In the case of a non-HOT UPDATE the backend will see the index entry
> > for the old row version and then check it, pointlessly. Since that has
> > just been modified, that won't ever be killed, so skipping the check
> > makes sense in those cases.
>
> I agree that the check itself is pointless here. But that in itself
> doesn't make the call to _bt_check_unique() useless. It might still
> manage to set LP_DEAD bits when nothing else will.
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.
So the check isn't going to do anything useful in the vast majority of
cases, which is why its OK to remove it.
--
Simon Riggs http://www.EnterpriseDB.com/