* Tom Lane (t...@sss.pgh.pa.us) wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: > > On 10 March 2014 03:36, Craig Ringer <cr...@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
Description: Digital signature