From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: AcquireRewriteLocks/acquireLocksOnSubLinks vs. rowsecurity |
Date: | 2015-08-28 12:49:24 |
Message-ID: | 20150828124924.GT3685@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* 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
Attachment | Content-Type | Size |
---|---|---|
fix-rls-locking.patch | text/x-diff | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-08-28 12:53:34 | Re: AcquireRewriteLocks/acquireLocksOnSubLinks vs. rowsecurity |
Previous Message | jacques klein | 2015-08-28 10:30:54 | NOTIFY in Background Worker |