Re: Broken lock management in policy.c.

Tom, Peter,

On Sunday, January 3, 2016, Peter Geoghegan <pg(at)heroku(dot)com> wrote:

> On Sun, Jan 3, 2016 at 4:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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