Re: BUG #13988: "plan should not reference subplan's variable" whilst using row level security

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, asguthrie(at)gmail(dot)com, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #13988: "plan should not reference subplan's variable" whilst using row level security
Date: 2016-02-26 00:55:08
Message-ID: 25223.1456448108@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> Debugging it, I have a theory as to the cause of the problem, which I
> think is in security_barrier_replace_vars() --- when it finds a
> matching Var that needs to be added to the targetlist that it is
> building, it copies the existing Var and modifies it:

> /* New variable for subquery targetlist */
> newvar = copyObject(var);
> newvar->varno = newvar->varnoold = 1;
> ...

> However, the Var found comes from a sublink subquery in the outer
> query, and so has varlevelsup = 1, but newvar is for the new subquery
> being built, so it needs to have varlevelsup set to 0, which that code
> fails to do.

Offhand, I'd think it more likely that this code should not be touching
outer-level vars at all? There are few if any situations where it makes
sense to suppose that a Var of one level should be transformed into a Var
of a different level.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2016-02-26 01:44:36 Re: BUG #13990: Postgres shutting down automatically
Previous Message Dean Rasheed 2016-02-25 23:32:12 Re: BUG #13988: "plan should not reference subplan's variable" whilst using row level security