From: Tom Lane <tgl@sss.pgh.pa.us>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: 253540651@qq.com, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #17151: A SEGV in optimizer
Date: Wed, 18 Aug 2021 11:55:58 -0400
Message-ID: <1458262.1629302158@sss.pgh.pa.us> (raw)
In-Reply-To: <CAD21AoAC0qpejrwWynTBtzqbd2=xcqP_wJ8=ydFydjAwc4n9_w@mail.gmail.com>
References: <17151-c03a3e6e4ec9aadb@postgresql.org>
<CAD21AoAC0qpejrwWynTBtzqbd2=xcqP_wJ8=ydFydjAwc4n9_w@mail.gmail.com>
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
Attachments:dont-lock-OLD-and-NEW.patch (text/x-diff, 798B) downloaddiff --git a/src/backend/parser/analyze.c b/src/backend/parser/analyze.cindex 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)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, sawada.mshk@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17151: A SEGV in optimizer
In-Reply-To: <1458262.1629302158@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox