Re: More FOR UPDATE/FOR SHARE problems - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: More FOR UPDATE/FOR SHARE problems
Date
Msg-id 497D94F7.EE98.0025.0@wicourts.gov
Whole thread Raw
In response to Re: More FOR UPDATE/FOR SHARE problems  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: More FOR UPDATE/FOR SHARE problems  (Jeff Davis <pgsql@j-davis.com>)
Re: More FOR UPDATE/FOR SHARE problems  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
>>> Tom Lane <tgl@sss.pgh.pa.us> wrote: 
> Jeff Davis <pgsql@j-davis.com> writes:
>> There you see a snapshot of the table that never existed. Either
the
>> snapshot was taken before the UPDATE, in which case i=3 should be
>> included, or it was taken after the UPDATE, in which case i=4 should
be
>> included. So atomicity is broken for WHERE.
> 
> This assertion is based on a misunderstanding of what FOR UPDATE in
> read-committed mode is defined to do.  It is supposed to give you
the
> latest available rows.
Well, technically it's violating the Isolation part of ACID, not the
Atomicity, since the UPDATE transaction will either commit or roll
back in its entirety, but another transaction can see it in an
intermediate (partially applied) state.[1]
I guess the issue of whether this violation of ACID properties should
be considered a bug or a feature is a separate discussion, but calling
it a feature seems like a hard sell to me.
-Kevin
[1] http://en.wikipedia.org/wiki/ACID



pgsql-hackers by date:

Previous
From: "Jonah H. Harris"
Date:
Subject: Re: 8.4 release planning
Next
From: Greg Smith
Date:
Subject: pgtune: postgresql.conf wizard