* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> That sounds a bit confused.
It was- I clearly hadn't followed the thread entirely.
> 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.
This, imv, moves this from a 'major' bug to more of a 'performance' or
'obnoxious' side-effect issue that we should address *eventually*, but
not something to hold up the RLS implementation. We often have more
locking than is strictly required and then reduce it later (see also:
ALTER TABLE lock reduction thread). It will be an unfortunate "gotcha"
for a release or two, but hopefully we'll be able to address it...
> [ 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.
Interesting. I'm trying to reason out why we don't have it already in
similar situations; we can't *always* flatten a subquery... Updatable
security_barrier views and RLS may make this a more promenint issue but
hopefully that'll just encourage work on fixing it (perhaps take the
higher level lock and then figure out a way to drop it when the rows
don't match the later quals..?).
> 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.
Agreed.
Thanks!
Stephen