Re: AcquireRewriteLocks/acquireLocksOnSubLinks vs. rowsecurity - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: AcquireRewriteLocks/acquireLocksOnSubLinks vs. rowsecurity
Date
Msg-id 20150828124924.GT3685@tamriel.snowman.net
Whole thread Raw
In response to Re: AcquireRewriteLocks/acquireLocksOnSubLinks vs. rowsecurity  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: AcquireRewriteLocks/acquireLocksOnSubLinks vs. rowsecurity  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
* Dean Rasheed (dean.a.rasheed@gmail.com) wrote:
> On 27 August 2015 at 13:49, Andres Freund <andres@anarazel.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

Attachment

pgsql-hackers by date:

Previous
From: jacques klein
Date:
Subject: NOTIFY in Background Worker
Next
From: Andres Freund
Date:
Subject: Re: AcquireRewriteLocks/acquireLocksOnSubLinks vs. rowsecurity