Re: [PATCH] Improve error message when trying to lock virtual tuple.

From: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
To: Sven Klemm <sven(at)timescale(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Improve error message when trying to lock virtual tuple.
Date: 2024-06-17 20:25:09
Message-ID: CAEze2WivuhGMdEZD4X_1eF6AE=XrJh2vQAB=go69kNJPcMoSfw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(now send a copy to -hackers, too)

On Mon, 17 Jun 2024 at 17:55, Sven Klemm <sven(at)timescale(dot)com> wrote:
>
> Hello,
>
> When currently trying to lock a virtual tuple the returned error
> will be a misleading `could not read block 0`. This patch adds a
> check for the tuple table slot being virtual to produce a clearer
> error.
>
> This can be triggered by extensions returning virtual tuples.
> While this is of course an error in those extensions the resulting
> error is very misleading.

I think you're solving the wrong problem here, as I can't think of a
place where both virtual tuple slots and tuple locking are allowed at
the same time in core code.

I mean, in which kind of situation could we get a Relation's table
slot which is not lockable by said relation's AM? Assuming the "could
not read block 0" error comes from the heap code, why does the
assertion in heapam_tuple_lock that checks for a
BufferHeapTupleTableSlot not fire before this `block 0` error? If the
error is not in the heapam code, could you show an example of the code
that breaks with that error code?

Kind regards,

Matthias van de Meent
Neon (https://neon.tech)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-06-17 20:37:05 Xact end leaves CurrentMemoryContext = TopMemoryContext
Previous Message David E. Wheeler 2024-06-17 20:07:49 Re: FYI: LLVM Runtime Crash