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

Поиск
Список
Период
Сортировка
Искать
От
Aleksander Alekseev
Тема
Re: [PATCH] Improve error message when trying to lock virtual tuple.
Дата
Msg-id
CAJ7c6TOx+0K-k3PNuDniC=8a+j+skm+KZDEmEv+1Hw0rGVY4-Q@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. Matthias van de Meent <boekewurm+postgres@gmail.com>
Re: [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. Matthias van de Meent <boekewurm+postgres@gmail.com>
Re: [PATCH] Improve error message when trying to lock virtual tuple. Aleksander Alekseev <aleksander@timescale.com>
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


В списке pgsql-hackers по дате отправления
От: Tomas Vondra
Дата:
От: Andrew Dunstan
Дата:
FAQ