Re: Select For Update and Left Outer Join
От | Kevin Grittner |
---|---|
Тема | Re: Select For Update and Left Outer Join |
Дата | |
Msg-id | 4E1AE4A2020000250003F1AE@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: Select For Update and Left Outer Join (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Select For Update and Left Outer Join
Re: Select For Update and Left Outer Join Re: Select For Update and Left Outer Join |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: