Re: More FOR UPDATE/FOR SHARE problems

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!

In response to

Browse pgsql-hackers by date

  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