From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17972: Assert failed in pull_varattnos_walker() for view with subquery and security qual
Date: Tue, 13 Jun 2023 16:06:57 -0400
Message-ID: <1798406.1686686817@sss.pgh.pa.us> (raw)
In-Reply-To: <17972-f422c094237847d0@postgresql.org>
References: <17972-f422c094237847d0@postgresql.org>
PG Bug reporting form <noreply@postgresql.org> writes:
> The following script:
> CREATE TABLE t1(a int);
> CREATE VIEW v1 WITH (security_barrier = true) AS SELECT a FROM t1;
> CREATE RULE v1_upd_rule AS ON UPDATE TO v1 DO INSTEAD UPDATE t1 SET a =
> NEW.a WHERE a = OLD.a;
> CREATE VIEW v2 WITH (security_barrier = true) AS SELECT a FROM v1 WHERE
> EXISTS (SELECT 1);
> UPDATE v2 SET a = 1;
> leads to a failed assertion with the stack trace:
Thanks for the report!
pull_varattnos is not at fault here. The problem is that we missed
converting that SubLink to a SubPlan earlier, because hasSubLinks
wasn't set in the parent Query, so we never called SS_process_sublinks.
After some digging, I found the cause: rewriteRuleAction neglected to
check for SubLink nodes in the securityQuals of range table entries.
> `git bisect` for this anomaly pointed at 215b43cdc.
I think this is just accidental, probably an artifact of the
specific test case. The oversight in rewriteRuleAction is as
old as the existence of RangeTblEntry.securityQuals, unless it
was impossible to write a SubLink in security quals before,
which I doubt.
regards, tom lane
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, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17972: Assert failed in pull_varattnos_walker() for view with subquery and security qual
In-Reply-To: <1798406.1686686817@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