Re: Broken lock management in policy.c.

On Sun, Jan 3, 2016 at 6:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm going to state it as an incontrovertible fact that that paragraph
> is so vague as to be useless, because I sure misunderstood it, and in
> fact just copy-edited it to talk about changes to RLS policies. I now
> see that it did say "relations referenced by RLS policies", but that
> distinction is going to escape just about everybody who does not already
> know what effects are being obliquely referred to.

That's fair.

> I think we should get rid of it altogether (since I also agree with the
> upthread comment that it's in the wrong place) and instead put an example
> into section 5.7 saying directly that sub-selects, or in general
> references to rows other than the one under test, are risky in RLS
> policies. We could also show the FOR UPDATE workaround there.

I agree that there should be a worked out example. After all, EPQ is a
behavior that is peculiar to Postgres, and the problem hinges on EPQ
being how READ COMMITTED conflicts are handled. An equivalent RLS
feature in any other database system (including other MVCC systems)
would naturally not have this problem, for reasons peculiar to the
other systems.

--
Peter Geoghegan