Horton

Re: Visibility bug in tuple lock

Jasper Smit <jbsmit@gmail.com>

View thread
From: Jasper Smit <jbsmit@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-12-18T09:56:25Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix bug in following update chain when locking a heap tuple

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