Re: BUG #17972: Assert failed in pull_varattnos_walker() for view with subquery and security qual
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Date: 2023-06-13T20:06:57Z
Lists: pgsql-bugs
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
Commits
-
Correctly update hasSubLinks while mutating a rule action.
- 792213f2e9f6 16.0 landed
- d1423c52e3f0 14.9 landed
- cc6974df16e0 15.4 landed
- b4110bdbfe9d 12.16 landed
- a36d0014f11f 13.12 landed
- 13192a324ad8 11.21 landed