(now send a copy to -hackers, too) On Mon, 17 Jun 2024 at 17:55, Sven Klemm <s...@timescale.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)
