[ getting back to this now that there's a little time ] Peter Geoghegan <p...@heroku.com> writes: > On Sun, Jan 3, 2016 at 7:01 PM, Peter Geoghegan <p...@heroku.com> wrote: >> I would also advise only referencing a single relation within the >> SELECT FOR UPDATE.
> To state what may be obvious: We should recommend that SELECT FOR > SHARE appear in the CREATE POLICY USING qual as part of this > workaround (not SELECT FOR UPDATE), because there is no need for > anything stronger than that. We only need to prevent the admin > updating a referenced-in-using-qual tuple in a way that allows a > malicious user to exploit an inconsistency in tuple visibility during > EPQ rechec. (Using SELECT FOR KEY SHARE would not reliably workaround > the underlying issue, though.) Right, SELECT FOR SHARE would be sufficient and would reduce the concurrency penalty a bit. It might be possible to use SELECT FOR KEY SHARE if you knew that the column you needed to check was a unique-key column, but that seems unlikely to be common, so I think we can omit the point from our example. I'll go draft something up ... regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers