Re: More FOR UPDATE/FOR SHARE problems

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: <npboley(at)gmail(dot)com>,"Jeff Davis" <pgsql(at)j-davis(dot)com>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: More FOR UPDATE/FOR SHARE problems
Date: 2009-02-04 16:26:35
Message-ID: 49896D5B.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Well, with no one replying, :-(, I went ahead and added to the Read
> Committed section of our manual to show a simple case where our read
> committed mode produces undesirable results. I also did a little
> cleanup at the same time.
>
> You can see the resulting text here:
>
>
http://momjian.us/tmp/pgsql/transaction-iso.html#XACT-READ-COMMITTED

So READ COMMITTED allows a single SQL statement to see and act upon a
database state which represents partial completion of a concurrent
database transaction? I'm not sure whether the SQL spec explicitly
prohibits that, but it does seem surprising and potentially dangerous.

At a minimum, the documentation you suggest seems wise. If that can
be prevented, I think it should be. Seriously, this would justify
giving up the guarantee that serialization failures can't happen in
PostgreSQL in READ COMMITTED mode. That guarantee is not required by
the standard, is not present in many databases, and to me it is less
important that accurate results.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-02-04 16:35:19 Re: add_path optimization
Previous Message Alvaro Herrera 2009-02-04 16:22:23 <note> on hash indexes