Tom, Peter, On Sunday, January 3, 2016, Peter Geoghegan <p...@heroku.com> wrote:
> On Sun, Jan 3, 2016 at 4:32 PM, Tom Lane <t...@sss.pgh.pa.us <javascript:;>> > wrote: > > CREATE POLICY takes AccessExclusiveLock on the table a policy is being > > added to -- good -- and then releases it when done -- bad. Correct > > behavior is to hold the lock till commit, because otherwise there is > > no guarantee that other backends will see the updated catalog rows in > > time, or indeed at all. > > > > The same goes for ALTER POLICY, and possibly DROP POLICY (I've not > > found the implementation of that ...) > > Right. > > > If we fix this, I believe we could also remove the weasel wording that > was > > added to create_policy.sgml in commit 43cd468cf01007f3 about how the > > system might transiently fail to enforce row security correctly. > > IIUC, then what you say here isn't true, because that issue was about > a transient failure without the involvement of *any* DDL from start to > finish. CREATE POLICY accepts subqueries referencing other relations > in its USING quals. This seems to be idiomatic usage of CREATE POLICY, > in fact. > > See my original isolation tester test case, where only the setup involves > DDL: > > > http://www.postgresql.org/message-id/attachment/38467/0001-RLS-isolation-test.patch > Further, as mentioned in the discussion of that issue- it also can apply to updatable security barrier views. It's not specific to RLS. Thanks, Stephen
