Re: BUG #17151: A SEGV in optimizer
Tom Lane <tgl@sss.pgh.pa.us>
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>
Date: 2021-08-18T15:55:58Z
Lists: pgsql-bugs
Attachments
- dont-lock-OLD-and-NEW.patch (text/x-diff) patch
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
Commits
-
Avoid trying to lock OLD/NEW in a rule with FOR UPDATE.
- cc7fae5c2d9e 9.6.24 landed
- 2739a281060f 10.19 landed
- fbc1eed8a8dd 11.14 landed
- 8d2d6ec7708b 15.0 landed
- 7fa367d96bb1 13.5 landed
- 464900393352 14.0 landed
- 0c13ee198f0d 12.9 landed