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

From Peter Geoghegan
Subject Re: Broken lock management in policy.c.
Date
Msg-id CAM3SWZStaFgYPE0922-=MewxvuPKbwd=Xzh0diRkw-qpmM6bog@mail.gmail.com
Whole thread Raw
In response to Re: Broken lock management in policy.c.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Broken lock management in policy.c.  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On Sun, Jan 3, 2016 at 6:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

That's fair.

> 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.

I agree that there should be a worked out example. After all, EPQ is a
behavior that is peculiar to Postgres, and the problem hinges on EPQ
being how READ COMMITTED conflicts are handled. An equivalent RLS
feature in any other database system (including other MVCC systems)
would naturally not have this problem, for reasons peculiar to the
other systems.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Ian Barwick
Date:
Subject: Description tweak for vacuumdb
Next
From: Tom Lane
Date:
Subject: Re: Broken lock management in policy.c.