* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> > On 10 March 2014 03:36, Craig Ringer <craig@2ndquadrant.com> wrote:
> >> I've found an issue with updatable security barrier views. Locking is
> >> being pushed down into the subquery. Locking is thus applied before
> >> user-supplied quals are, so we potentially lock too many rows.
>
> > That has nothing to do with *updatable* security barrier views,
> > because that's not an update. In fact you get that exact same plan on
> > HEAD, without the updatable security barrier views patch.
>
> I got around to looking at this.
Thanks!
> So if you wanted user-supplied quals to limit which rows get locked
> physically, they would need to be applied before the lower LockRows node.
Right.
> To my mind, it's not immediately apparent that that is a reasonable
> expectation. The entire *point* of a security_barrier view is that
> unsafe quals don't get pushed into it, so why would you expect that
> those quals get applied early enough to limit locking?
Right, we don't want unsafe quals to get pushed down below the
security_barrier view. The point here is that those quals should not be
able to lock rows which they don't even see.
My understanding of the issue was that the unsafe quals were being able
to see and lock rows that they shouldn't know exist. If that's not the
case then I don't think there's a bug here..? Craig/Dean, can you
provide a complete test case which shows the issue?
Thanks, Stephen