Re: determine snapshot after obtaining locks for first statement - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: determine snapshot after obtaining locks for first statement
Date
Msg-id 4B2A2139020000250002D719@gw.wicourts.gov
Whole thread Raw
In response to Re: determine snapshot after obtaining locks for first statement  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: determine snapshot after obtaining locks for first statement  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: determine snapshot after obtaining locks for firststatement  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> After thinking a bit, I'd be inclined to add a new paragraph.
> In particular, now that FOR UPDATE actually works in subqueries,
> it'd be worth pointing out that you can add that to guard against
> this type of issue.  Perhaps, after the "DELETE FROM website"
> example, we could add something like
> 
> UPDATEs and DELETEs involving joins or subqueries are particularly
> at risk, since they may perform an update based on a combination
> of old rows from other tables with an up-to-date target row.  This
> risk can be mitigated by adding FOR UPDATE or FOR SHARE to
> subqueries, so that all rows directly involved in an update are
> guaranteed current.  However that will also increase the risk of
> deadlock failures.
Much better than my suggestion.  Including both the problem
conditions and the solution is ideal.
I'd missed that we now allow FOR UPDATE and FOR SHARE on subqueries.
Nice enhancement.
-Kevin


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: determine snapshot after obtaining locks for first statement
Next
From: Tom Lane
Date:
Subject: Re: determine snapshot after obtaining locks for first statement