Обсуждение: Serializable isolation level
I need you expert opinions on the following statement. The primary reason I use serialized transactions is to avoid race conditions. One of postgresql's famed features is the MVCC (multi-version concurrency control) aka serialized transactions, which allows you to avoid using row/table level locks. It's *supposed* to keep things moving much more quickly than locks allow for. Thanks, Steve.
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