[ 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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
