Re: Visibility bug in tuple lock

The test is really nice with the injection points and the dynamically
sized data.

> Ah, but this codepath is taken when HEAP_KEYS_UPDATED is *not* set. I
> got that backwards. So I agree the ItemPointerEquals(&tuple->t_self,
> ctid) check is redundant.

Ok, I did not think about deletes. So the boolean updated here could
mean both update and delete, that makes sense to me.

> I chatted about that with Andres Freund just the other day, and he said
> that compilers are not good at optimizing passing them by value. I'll
> take his word on that.

I believe that too, but in heap_lock_updated_tuple_rec() the first
thing we do is ItemPointerCopy(tid, &tupid); , which makes it probably
just as inefficient.

Jasper