X-Original-To: pgsql-docs@postgresql.org Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 1DB38477151 for ; Tue, 4 Mar 2003 19:25:05 -0500 (EST) Received: from postgresql.org ([64.49.215.8]) by localhost (postgresql.org [64.49.215.8:10024]) (amavisd-new) with SMTP id 80341-03 for ; Tue, 4 Mar 2003 19:24:58 -0500 (EST) Received: from iguana.simplexity.net (adsl-216-103-84-145.dsl.snfc21.pacbell.net [216.103.84.145]) by postgresql.org (Postfix) with ESMTP id 76E09488399 for ; Tue, 4 Mar 2003 15:58:36 -0500 (EST) Received: from localhost (miu9q3353ic40kqv@localhost [127.0.0.1]) by iguana.simplexity.net (8.12.3/8.12.3) with ESMTP id h24KwPQ1080456; Tue, 4 Mar 2003 12:58:27 -0800 (PST) (envelope-from ocrow@simplexity.net) Date: Tue, 4 Mar 2003 12:58:25 -0800 (PST) From: Oliver Crow To: pgsql-docs@postgresql.org, Subject: Read Committed isolation Message-ID: <20030304125718.W74791-100000@iguana.simplexity.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Archive-Number: 200303/2 X-Sequence-Number: 1680 Hi all, It seems to me that the PostgreSQL user's manual could be clearer on the consequences of using the Read Committed isolation level. It says "The partial transaction isolation provided by Read Committed mode is adequate for many applications" ... "However, for applications that do complex queries and updates, it may be necessary to guarantee a more rigorously consistent view of the database". It does not say what types of transactions will cause problems in Read Committed mode, or what the consequences of those problems might be. This is a point on which the manual ought to be explicit ... the potential for intermittent creation of database inconsistencies is serious. For example, if information from a select is passed via the application to an update, the transaction could reintroduce stale information. This message provides some good explanation with examples: http://archives.postgresql.org/pgsql-hackers/2002-04/msg00150.php It also speaks clearly about when a serializable transaction may need to be repeated, and the possible trade off between using serializable or SELECT FOR UPDATE. Could an edited version of that message be included in the manual? (I'd be willing to assist with editing) Thanks, Oliver