From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | Sven Klemm <sven(at)timescale(dot)com> |
Subject: | Re: [PATCH] Improve error message when trying to lock virtual tuple. |
Date: | 2024-06-17 16:12:31 |
Message-ID: | CAJ7c6TOx+0K-k3PNuDniC=8a+j+skm+KZDEmEv+1Hw0rGVY4-Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
> 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.
```
+ /*
+ * If the slot is virtual, we can't lock it. This should never happen, but
+ * this will lead to a misleading could not read block error
later otherwise.
+ */
```
I suggest dropping or rephrasing the "this should never happen" part.
If this never happened we didn't need this check. Maybe "If the slot
is virtual, we can't lock it. Fail early in order to provide an
appropriate error message", or just "If the slot is virtual, we can't
lock it".
```
elog(ERROR, "cannot lock virtual tuple");
```
For some reason I thought that ereport() is the preferred way of
throwing errors, but I see elog() used many times in ExecLockRows() so
this is probably fine.
--
Best regards,
Aleksander Alekseev
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2024-06-17 16:21:10 | Re: RFC: adding pytest as a supported test framework |
Previous Message | Tomas Vondra | 2024-06-17 16:10:45 | Re: using extended statistics to improve join estimates |