Database Reference
In-Depth Information
first-come-first-served order. The final result of the data is what most people would
naturally expect, reflecting the last chronological change.
PostgreSQL does not provide any way to do a dirty read. A dirty read is the ability
to view the data the way it appears in someone else's transaction, and use it as if it
were committed. This ability is not available in PostgreSQL because of the way that
the multi-version concurrency control works.
There are other transaction isolation methods available, you can read about them in
It is important to note that when no transaction blocks are specified (
BEGIN ..
END
), that PostgreSQL will treat each individual statement like a private transaction,
and commit immediately when the statement is finished. This gives other transac-
tions a chance to settle in between your statements. Some programming languages
provide a transaction block around your statements, while some do not. Please
check your language documentation to find out if you are running in a transacted
session.
Note
When using the two main clients to interact with PostgreSQL, the transaction be-
havior is different. The
psql
command line client does not provide transaction
blocks for you. You are expected to know when to start/stop a transaction on
your own. The
pgAdmin3
query window on the other hand wraps any statement
that you submit into a transaction block for you. This is the way that it provides a
cancel
option. If the transaction is interrupted, a ROLLBACK will be performed
and the database will go back to it's former state.
Some operations are exempt from transactions. For example, a
sequence
object
will continue to increment even if the transaction fails and is rolled back.
CREATE
INDEX CONCURRENTLY
requires management of it's own transactions, and should
not be called from within a transaction block. The same is true with
VACUUM
as well
as
CLUSTER
.
