Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@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