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

From Joshua D. Drake
Subject Re: determine snapshot after obtaining locks for first statement
Date
Msg-id 1261073093.22798.28.camel@jd-desktop.iso-8859-1.charter.com
Whole thread Raw
In response to Re: determine snapshot after obtaining locks for first statement  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, 2009-12-17 at 12:58 -0500, Robert Haas wrote:
> On Thu, Dec 17, 2009 at 12:51 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
> > Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> >> I'm not very sure what a clearer explanation would look like
> >
> > As a stab at it, how about?:
> >
> > This behavior makes Read Committed mode unsuitable for many UPDATE
> > or DELETE commands with joins or subqueries
> 
> I don't think that's any clearer, though it is more disparaging.  :-)
> 
> Note we also say: "The partial transaction isolation provided by Read
> Committed mode is adequate for many applications, and this mode is
> fast and simple to use; however, it is not sufficient for all cases.
> Applications that do complex queries and updates might require a more
> rigorously consistent view of the database than Read Committed mode
> provides."

What is needed here is a layman's context of what isolation modes are
good for what type of operation. Neither your explanation or Tom's is
particularly useful except to say, "Crap, I might be screwed but I don't
know if I am... how do I find out?"

Joshua D. Drake



> 
> ...Robert
> 


-- 
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
If the world pushes look it in the eye and GRR. Then push back harder. - Salamander



pgsql-hackers by date:

Previous
From: Takahiro Itagaki
Date:
Subject: Re: Largeobject Access Controls (r2460)
Next
From: Robert Haas
Date:
Subject: Re: patch - per-tablespace random_page_cost/seq_page_cost