Re: AcquireRewriteLocks/acquireLocksOnSubLinks vs. rowsecurity

* Dean Rasheed (dean(dot)a(dot)rasheed(at)gmail(dot)com) wrote:
> On 27 August 2015 at 13:49, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > The locking around rowsecurity policy expressions seems to be
> > insufficient:
> > SELECT * FROM document WHERE f_leak(dtitle) ORDER BY did;
> > WARNING: RelationIdGetRelation(247984) without holding lock on the relation
> > WARNING: relation_open(247984, NoLock) of relation "uaccount" without previously held lock
[...]
> > Istmt that something like
> > context.for_execute = true;
> > acquireLocksOnSubLinks((Node *) securityQuals, &context);
> > acquireLocksOnSubLinks((Node *) withCheckOptions, &context);
> > needs to be added to that code.
>
> Yes, I think you're right. It needs to happen before fireRIRonSubLink,
> and only if hasSubLinks is true.

Attached appears to fix this for the RLS case from my testing.

Any comments?

Barring concerns, I'll push this later today and back-patch to 9.5.

Thanks!

Stephen