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. -- Regards, Sven Klemm
From c5ccbf2e9cb401a7e63e93cd643b4dfec8d92ab8 Mon Sep 17 00:00:00 2001 From: Sven Klemm <s...@timescale.com> Date: Mon, 17 Jun 2024 17:38:27 +0200 Subject: [PATCH] Improve error message when trying to lock virtual tuple. 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. --- src/backend/executor/nodeLockRows.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/backend/executor/nodeLockRows.c b/src/backend/executor/nodeLockRows.c index 41754ddfea..cb3abbd348 100644 --- a/src/backend/executor/nodeLockRows.c +++ b/src/backend/executor/nodeLockRows.c @@ -65,6 +65,13 @@ lnext: return NULL; } + /* + * 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. + */ + if (TTS_IS_VIRTUAL(slot)) + elog(ERROR, "cannot lock virtual tuple"); + /* We don't need EvalPlanQual unless we get updated tuple version(s) */ epq_needed = false; -- 2.45.2
