Tom, Peter,
On Sunday, January 3, 2016, Peter Geoghegan <
pg@heroku.com> wrote:
On Sun, Jan 3, 2016 at 4:32 PM, Tom Lane <tgl@sss.pgh.pa.us> 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
