Re: More FOR UPDATE/FOR SHARE problems

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

>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2009-01-26 16:55:14 pgtune: postgresql.conf wizard
Previous Message Jonah H. Harris 2009-01-26 16:44:31 Re: 8.4 release planning