Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wwcYZ-0025ik-21 for pgsql-bugs@arkaria.postgresql.org; Wed, 19 Aug 2026 09:25:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wwcYY-002hHO-1B for pgsql-bugs@arkaria.postgresql.org; Wed, 19 Aug 2026 09:25:58 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wwXMP-001Npq-12 for pgsql-bugs@lists.postgresql.org; Wed, 19 Aug 2026 03:53:06 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wwXMO-00000001KTg-30JL for pgsql-bugs@lists.postgresql.org; Wed, 19 Aug 2026 03:53:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:Cc:From:To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Content-ID: Content-Description:In-Reply-To:References; bh=5vIUNk4hBuU9dNmZw1kLMdnmGsjQ5DuCgOvPdTVE/b4=; b=d5AKE+jD2jQ7kzaxvGcIu3j3n5 tNdULR0Ceg3vHsyGre2YfnbqPrc1od6MlR/j6kpKDFhYq2Pz4tBb1bpfwG8Qumd6QgAC+3ztNxmOj bito/PrEXEGgdflUL+blveAA1rCWshaNIuhpjAsPs9wiv8hH7S/c5mE53KoS5LWs7b5Mj5EMh6XOI S5BEr4lfB8squuALkPqja11KZV7slYgWRI/wX+H0VGywQzKvv2jgx4K67WIJHH8dsBQaCmZldngAF YemWATnwrYmCrKjW0Tm1OyHles2DNue50h2HLVr3/hmHiI8VIgfWiEJi2cBL7jrr1Z1tX2TAXutJm Y4sf8xbg==; Received: from wrigleys.postgresql.org ([2a02:16a8:dc51::60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wwXMO-0043uF-1O for pgsql-bugs@lists.postgresql.org; Wed, 19 Aug 2026 03:53:04 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1wwXMN-0000000AXzS-1gbA for pgsql-bugs@lists.postgresql.org; Wed, 19 Aug 2026 03:53:03 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19632: RULE rewriting crashes with XX000 when RETURNING old/new references a system column To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: hackerzheng666@gmail.com Reply-To: hackerzheng666@gmail.com, pgsql-bugs@lists.postgresql.org Date: Wed, 19 Aug 2026 03:52:11 +0000 Message-ID: <19632-9155d9baec763c8c@postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk The following bug has been logged on the website: Bug reference: 19632 Logged by: Zheng Hacker Email address: hackerzheng666@gmail.com PostgreSQL version: 19beta3 Operating system: Linux x86_64 Description: =20 PostgreSQL version: 20devel (commit bdbf662, 2026-08-19) OS: Linux x86_64 =20 When a DML query with RETURNING old. or RETURNING new. (PG 20 new syntax) is rewritten through a RULE, the query rewriter cannot find replacement targetlist entries for system columns, hitting elog(ERROR) in rewriteManip.c. =20 Reproducer: =20 CREATE TABLE t (a int); INSERT INTO t VALUES (1); CREATE RULE t_del AS ON DELETE TO t DO INSTEAD UPDATE t SET a =3D -1 WHERE a =3D OLD.a RETURNING *; =20 -- All of these crash with XX000: DELETE FROM t WHERE a =3D 1 RETURNING old.tableoid; -- ERROR: XX000: could not find replacement targetlist entry for attno -6 -- LOCATION: ReplaceVarFromTargetList, rewriteManip.c:1884 =20 DELETE FROM t WHERE a =3D 1 RETURNING old.ctid; -- attno -1 DELETE FROM t WHERE a =3D 1 RETURNING new.tableoid; -- attno -6 =20 -- Without the RULE, the same RETURNING clause works correctly: DROP RULE t_del ON t; DELETE FROM t WHERE a =3D 1 RETURNING old.tableoid; -- works fine =20 Root cause: src/backend/rewrite/rewriteManip.c, function ReplaceVarFromTargetList (line 1884). When the rewriter processes the RULE's action to replace Vars, it iterates over the action's target list looking for an entry with matching resno. System columns have negative attribute numbers (e.g. tableoid =3D -6), but the RULE's RETURNING target list only contains user-defined columns (with positive resnos), so no match is found. =20 The PG 20 old/new RETURNING syntax (var->varreturningtype !=3D VAR_RETURNING_DEFAULT) is handled AFTER the targetlist entry lookup succeeds (lines 1894-1910), so the code never reaches that logic for system columns. =20 Affects all system columns (tableoid, ctid, xmin, cmin, xmax) through any RULE that uses DO INSTEAD. Found by automated SQL fuzzing. Credit: Zheng Wang, Yanjie Zhao, Yiyang Liu