Read Committed isolation

Started by Oliver Crowabout 23 years ago2 messagesdocs
Jump to latest
#1Oliver Crow
ocrow@simplexity.net

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

#2Bruce Momjian
bruce@momjian.us
In reply to: Oliver Crow (#1)
Re: Read Committed isolation

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