Re: AcquireRewriteLocks/acquireLocksOnSubLinks vs. rowsecurity
Вложения
В списке pgsql-hackers по дате отправления:
| От | Stephen Frost |
|---|---|
| Тема | Re: AcquireRewriteLocks/acquireLocksOnSubLinks vs. rowsecurity |
| Дата | |
| Msg-id | 20150828124924.GT3685@tamriel.snowman.net обсуждение |
| Ответ на | Re: AcquireRewriteLocks/acquireLocksOnSubLinks vs. rowsecurity (Dean Rasheed <dean.a.rasheed@gmail.com>) |
| Ответы |
Re: AcquireRewriteLocks/acquireLocksOnSubLinks vs.
rowsecurity
|
| Список | 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
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера