Re: BUG #17151: A SEGV in optimizer
От | Tom Lane |
---|---|
Тема | Re: BUG #17151: A SEGV in optimizer |
Дата | |
Msg-id | 1458262.1629302158@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17151: A SEGV in optimizer (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: BUG #17151: A SEGV in optimizer
|
Список | pgsql-bugs |
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)
В списке pgsql-bugs по дате отправления: