Re: Broken lock management in policy.c.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Broken lock management in policy.c.
Дата
Msg-id 22839.1451873072@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Broken lock management in policy.c.  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: Broken lock management in policy.c.  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
Peter Geoghegan <pg@heroku.com> writes:
> On Sun, Jan 3, 2016 at 5:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In any case, the text in create_policy.sgml seems to be a misleading
>> description of the problem, as it's talking about DDL modifications
>> which are *not* what's happening here.

> I'm not sure what you mean. The CREATE POLICY changes in commit
> 43cd468cf01007f3 specifically call out the issue illustrated in my
> example test case. There are some other changes made in that commit,
> but they don't seem to be attempting to address this specific problem.
> They also seem fine.

I'm going to state it as an incontrovertible fact that that paragraph
is so vague as to be useless, because I sure misunderstood it, and in
fact just copy-edited it to talk about changes to RLS policies.  I now
see that it did say "relations referenced by RLS policies", but that
distinction is going to escape just about everybody who does not already
know what effects are being obliquely referred to.

I think we should get rid of it altogether (since I also agree with the
upthread comment that it's in the wrong place) and instead put an example
into section 5.7 saying directly that sub-selects, or in general
references to rows other than the one under test, are risky in RLS
policies.  We could also show the FOR UPDATE workaround there.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Broken lock management in policy.c.
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Broken lock management in policy.c.