Masahiko Sawada <sawada.mshk@gmail.com> writes:
> This seems to happen on all supported versions. A segmentation fault
> happens during "DELETE FROM v0". The minimum reproduce steps are:
> CREATE TABLE v0 ( v1 INTEGER ) ;
> CREATE RULE v1 AS
> ON DELETE TO v0 DO SELECT
> FOR UPDATE OF old;
> DELETE FROM v0 ;
> What happens in the DELETE statement is that LockRows node receives a
> tuple from Result node and attempts to acquire a row lock on it but it
> shouldn't. I guess that analyzing the SELECT query in rule v1 should
> raise an error in the first place since there is no 'old' table in its
> FROM clause. I'm still investigating this issue.
Agreed, this ought to be rejected. In the original case, OLD wasn't
mentioned explicitly, but the parser still attempted to lock it,
which is a slightly different bug.
I think that the fix might be as easy as the attached. In your
example, this would result in
ERROR: relation "old" in FOR UPDATE clause not found in FROM clause
which is not terribly specific, but it's not really wrong either.
Seeing that nobody has complained of this in ~20 years, I doubt
we need to work harder on the error message.
(This passes check-world, but I've not double-checked to make sure
that inFromCl will be set in exactly the cases we want.)
regards, tom lane
diff --git a/src/backend/parser/analyze.c b/src/backend/parser/analyze.c
index 438b077004..f715748d88 100644
--- a/src/backend/parser/analyze.c
+++ b/src/backend/parser/analyze.c
@@ -3177,6 +3177,8 @@ transformLockingClause(ParseState *pstate, Query *qry, LockingClause *lc,
RangeTblEntry *rte = (RangeTblEntry *) lfirst(rt);
++i;
+ if (!rte->inFromCl)
+ continue; /* ignore OLD/NEW in rules */
switch (rte->rtekind)
{
case RTE_RELATION:
@@ -3227,6 +3229,8 @@ transformLockingClause(ParseState *pstate, Query *qry, LockingClause *lc,
RangeTblEntry *rte = (RangeTblEntry *) lfirst(rt);
++i;
+ if (!rte->inFromCl)
+ continue; /* ignore OLD/NEW in rules */
if (strcmp(rte->eref->aliasname, thisrel->relname) == 0)
{
switch (rte->rtekind)
