Re: Broken lock management in policy.c. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Broken lock management in policy.c.
Date
Msg-id 22839.1451873072@sss.pgh.pa.us
Whole thread Raw
In response to Re: Broken lock management in policy.c.  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Broken lock management in policy.c.  (Peter Geoghegan <pg@heroku.com>)
List 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 by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Broken lock management in policy.c.
Next
From: Peter Geoghegan
Date:
Subject: Re: Broken lock management in policy.c.