From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "npboley\(at)gmail(dot)com" <npboley(at)gmail(dot)com> |
Subject: | Re: More FOR UPDATE/FOR SHARE problems |
Date: | 2009-01-25 02:45:32 |
Message-ID: | 87iqo4kss3.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)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!
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-01-25 04:00:04 | Re: [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle |
Previous Message | Tom Lane | 2009-01-25 01:53:27 | Re: More FOR UPDATE/FOR SHARE problems |