Robert Haas <robertmhaas@gmail.com> wrote:
> I find these responses to be a bit off point.
The OP is basically looking for what Florian tried to implement.
This is perhaps a *bit* off point, but arguably not more than
pointing someone who is requesting planner hints in another
direction. And someone thought the issues were related here:
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01792.php ;-)
> Not everyone can or will want to use SERIALIZABLE.
No argument on that. It's just that it is the only feature we have
now (or soon) which solves the problem short of a table lock.
> The OP's point is that we - particularly Tom - have argued in the
> past that we shouldn't allow this because it's too ill-defined
> and/or confusing.
And I have argued that what Florian wanted would be a valuable
addition. The approach foundered on technical details, although in
re-reading the thread I'm wondering if it wouldn't make sense to
dodge all that by having SELECT FOR UPDATE simple *do* a no-op
UPDATE RETURNING. This would cause behavior matching Oracle and MS
SQL Server (when the latter is using MVCC without S2PL). DB2 is
more strict, acquiring a predicate lock over the selected range, but
we can't be compatible with both behaviors at the same time.
> Evidently our competition does not agree
Neither on this nor on planner hints. ;-)
-Kevin
