Thread: Read Committed isolation

Read Committed isolation

From
Oliver Crow
Date:
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





Re: Read Committed isolation

From
Bruce Momjian
Date:
I guess the big question is whether we want to be teaching isolation
level concepts in our manual.  It is a standard database concept.

---------------------------------------------------------------------------

Oliver Crow wrote:
>
> 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
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073