Serializable isolation level

sknipe@tucows.com wrote:

I need you expert opinions on the following statement.

You have four statements here.

The primary reason I use serialized transactions is to avoid race
conditions.

Difficult to say why _you_ use them - they certainly can help there.
Make sure you read the bit on "true serializability" though.

One of postgresql's famed features is the MVCC
(multi-version concurrency control) aka serialized transactions

Umm - no. MVCC underlies how all the transaction levels are implemented,
though you could implement them via other methods.

which allows you to avoid using row/table level locks.

MVCC is designed to.

It's *supposed* to keep things moving much more
quickly than locks allow for.

It allows reads to proceed without waiting for writes (with the
understanding that what you read may now be out of date).

Does that help at all?
--
Richard Huxton
Archonet Ltd

Richard Huxton <dev@archonet.com> writes:

sknipe@tucows.com wrote:

I need you expert opinions on the following statement.

You have four statements here.

Also, no one of those statements is a reason for using serializable mode
instead of read committed mode, since they all apply to read committed
just as well. Real reasons for choosing one over the other have to do
with what your application logic looks like and what you are prepared to
do to recover from inconsistencies introduced by concurrent updates.
I would suggest reading the documentation at
http://developer.postgresql.org/docs/postgres/mvcc.html

regards, tom lane