Stephen Frost <sfr...@snowman.net> writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> 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. That sounds a bit confused. The quals aren't getting to see rows they shouldn't be allowed to see. The issue rather is whether rows that the user quals would exclude might get locked anyway because the locking happens before those quals are checked. [ thinks for awhile... ] I guess the thing that is surprising is that ordinarily, if you say SELECT ... WHERE ... FOR UPDATE, only rows passing the WHERE clause get locked. If there's a security view involved, that gets reversed (at least for unsafe clauses). So from that standpoint it does seem pretty bogus. I'm not sure how much we can do about it given the current implementation technique for security views. A physical row lock requires access to the source relation and the ctid column, neither of which are visible at all outside an un-flattened subquery. Anyway, this is definitely a pre-existing issue with security_barrier views (or really with any unflattenable subquery), and so I'm not sure if it has much to do with the patch at hand. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers