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

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

In response to

Browse pgsql-hackers by date

  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