Re: [PATCH] Improve error message when trying to lock virtual tuple.
От | Matthias van de Meent |
---|---|
Тема | Re: [PATCH] Improve error message when trying to lock virtual tuple. |
Дата | |
Msg-id | CAEze2WivuhGMdEZD4X_1eF6AE=XrJh2vQAB=go69kNJPcMoSfw@mail.gmail.com обсуждение исходный текст |
Ответ на | [PATCH] Improve error message when trying to lock virtual tuple. (Sven Klemm <sven@timescale.com>) |
Ответы |
Re: [PATCH] Improve error message when trying to lock virtual tuple.
|
Список | pgsql-hackers |
(now send a copy to -hackers, too) On Mon, 17 Jun 2024 at 17:55, Sven Klemm <sven@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)
В списке pgsql-hackers по дате отправления: