On Wed, Aug 18, 2021 at 4:12 PM PG Bug reporting form
<noreply@postgresql.org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 17151
> Logged by: Zhiyong Wu
> Email address: 253540651@qq.com
> PostgreSQL version: 14beta2
> Operating system: Linux version 5.13.0-1-MANJARO (builduser@LEGION)
> Description:
>
> PoC:
> CREATE TEMPORARY TABLE v0 ( v1 INTEGER ) ;
> CREATE RULE v1 AS ON DELETE TO v0 DO INSERT INTO v0 SELECT OFFSET - - - -1
> FOR UPDATE FOR UPDATE FOR SHARE FOR UPDATE FOR SHARE FOR SHARE ;
> ;
> DELETE FROM v0 ;
> ALTER TABLE v0 ADD UNIQUE ( v1 ) ;
Thank you for reporting!
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 ;
The plan of the DELETE statement is:
QUERY PLAN
-------------------------------------------------------------------
LockRows (cost=0.00..0.02 rows=1 width=6)
Output: v0.ctid
-> Result (cost=0.00..0.01 rows=1 width=6)
Output: v0.ctid
Delete on public.v0 (cost=0.00..35.50 rows=0 width=0)
-> Seq Scan on public.v0 (cost=0.00..35.50 rows=2550 width=6)
Output: ctid
(8 rows)
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.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/