Re: Improving RLS planning

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2016-12-29T15:55:54Z
Lists: pgsql-hackers
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> On 28 December 2016 at 19:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> [ getting back to this patch finally... ]  I made the suggested change
>> to that test case, and what I see is a whole lot of "NOTICE: snooped value
>> = whatever" outputs.
>> 
>> I'd leave it as shown in the attached diff fragment, except that I'm
>> a bit worried about possible platform dependency of the output.  The
>> hashing occurring in the subplans shouldn't affect output order, but
>> I'm not sure if we want a test output like this or not.  Thoughts?

> How about replacing "a = 3" with "a < 7 AND a != 6". That then
> exercises more of the possible types of behaviour for quals: The "a <
> 7" qual is pushed down and used as an index condition. The "a != 6"
> qual is pushed down and used as a filter, because it's cheap and
> leakproof. The leakproof() qual isn't pushed down on cost grounds. The
> snoop() qual isn't pushed down on security grounds. Both snoop() and
> leakproof() are used as filters, along with "a != 6", and a SB subplan
> qual. "a != 6" is executed first because it has a security_level of 0,
> and is cheaper than the subplan. snoop() is executed later, despite
> being cheaper than the other filter quals, because it has a higher
> security_level, and leakproof() is executed last because it has the
> same security level as snoop() but is more expensive.

Will do, although I think that the next test case (the one with "a = 8")
already shows most of those behaviors.

Maybe this one's just redundant and we should drop it?

			regards, tom lane


Commits

  1. Improve RLS planning by marking individual quals with security levels.