Jeff Davis <pg...@j-davis.com> writes: > On Sat, 2009-01-24 at 19:45 +0000, Greg Stark wrote: >> There already is quite an extensive discussion of how FOR UPDATE >> behaves including these kinds of violations. > > Not in the documentation, that I can see. And I think it's important > that it be there for the reasons I mentioned. > > Can you refer me to the dicussion that you're talking about? I don't > remember any discussion that points out that FOR UPDATE/FOR SHARE is > broken in the simple case of a simple WHERE clause.
http://www.postgresql.org/docs/8.3/static/transaction-iso.html#XACT-READ-COMMITTED Because of the above rule, it is possible for an updating command to see an inconsistent snapshot: it can see the effects of concurrent updating commands that affected the same rows it is trying to update, but it does not see effects of those commands on other rows in the database. This behavior makes Read Committed mode unsuitable for commands that involve complex search conditions. However, it is just right for simpler cases. For example, consider updating bank balances with transactions like ... -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
