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>
Cc: <npboley(at)gmail(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-01-26 20:31:39
Message-ID: 497DC94A.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>> Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> The tricky part is when an UPDATE with a search condition reads,
> modifies, and writes a value that is used in a search condition for
> another UPDATE.
>
> Every DBMS will block waiting for the first UPDATE to finish. Then
> what?

Either it's totally safe to proceed, or the second UPDATE was rolled
back.

> Do you re-run the query to find new tuples that might now satisfy
> the search condition that didn't before?

There can't be any. Blocks taken during the reading of rows so far
have not been released, and would preclude the update from changing
results read so far.

> Do you update the new value in all the tuples you originally found,
> regardless of whether they still match the search condition?

They have to still match, your locks would preclude their
modification.

> Do you update the new value in all the tuples that
> you found that still match the search condition?

They can't have a new value. Locks.

> Do you update the old value, perhaps overwriting changes made by the
> first UPDATE?

If you haven't gotten to reading rows yet, you're still OK by the time
the other transaction's locks are released. Look over those rules and
try some thought experiments to convince yourself. It really is safe,
if potentially slow.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2009-01-26 20:47:03 Re: 8.4 release planning
Previous Message dpage 2009-01-26 20:13:56 Re: 8.4 release planning