Re: Row-security on updatable s.b. views

On 03/07/2014 10:07 PM, Craig Ringer wrote:
> On 03/07/2014 09:33 PM, Craig Ringer wrote:
>> On 03/05/2014 11:02 AM, Craig Ringer wrote:
>>> The main known issue remaining is plan invalidation.
>>
>> I've pushed a version with a plan invalidation implementation. It's tagged:
>>
>> rls-9.4-upd-sb-views-v9
>>
>> in
>>
>> git(at)github(dot)com:ringerc/postgres.git
>>
>> The invalidation implementation does not yet handle foreign key checks;
>> that will require additional changes. I'll push an update to the
>> rls-9.4-upd-sb-views and post an update later, at which time I'll rebase
>> the changes back into the history.
>
> Well, that was easy. Done.
>
> rls-9.4-upd-sb-views-v11
>
> and rebased the rls-9.4-upd-sb-views branch to incorporate the changes.
>
> The regression tests have further failures, but some are due to changes
> in the inheritance semantics. I'm going through them now.
>

Need a quick opinion.

KaiGai's original code produced a plan like this for an inheritance set:

EXPLAIN (costs off) SELECT * FROM t1 WHERE f_leak(b) FOR SHARE;
! QUERY PLAN
! -------------------------------------------
LockRows
! -> Append
! -> Subquery Scan on t1
! Filter: f_leak(t1.b)
! -> Seq Scan on t1 t1_1
! Filter: ((a % 2) = 0)
! -> Subquery Scan on t2
! Filter: f_leak(t2.b)
! -> Seq Scan on t2 t2_1
! Filter: ((a % 2) = 1)
! -> Seq Scan on t3
! Filter: f_leak(b)
(12 rows)

The new code, using updatable s.b. views, instead produces:

EXPLAIN (costs off) SELECT * FROM t1 WHERE f_leak(b) FOR SHARE;
! QUERY PLAN
! -------------------------------------------------------
LockRows
! -> Subquery Scan on t1
! Filter: f_leak(t1.b)
! -> LockRows
! -> Result
! -> Append
! -> Seq Scan on t1 t1_1
! Filter: ((a % 2) = 0)
! -> Seq Scan on t2
! Filter: ((a % 2) = 0)
! -> Seq Scan on t3
! Filter: ((a % 2) = 0)
(12 rows)

The different quals are expected, because of the change to the
definition of inheritance handling in row security.

What I'm concerned about is the locking. It looks to me like we're
causing the user to lock rows that they may not intend to lock, by
applying a LockRows step *before* the user supplied qual. (I'm going to
test that tomorrow, it's sleep time in Australia).

This seems to be related to RowMark handling in updatable security
barrier views. I need to check whether it happens with updates to
security barrier views, as well as with row security.

Dean, any thoughts?

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services