mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-10-04 19:06:52 +02:00
More about chained mode and isolation levels.
This commit is contained in:
parent
3b9ef4d073
commit
962c66d83f
@ -10,7 +10,7 @@
|
|||||||
BEGIN WORK
|
BEGIN WORK
|
||||||
</REFNAME>
|
</REFNAME>
|
||||||
<REFPURPOSE>
|
<REFPURPOSE>
|
||||||
Begins a transaction
|
Begins a transaction in chained mode
|
||||||
</REFPURPOSE>
|
</REFPURPOSE>
|
||||||
|
|
||||||
</refnamediv>
|
</refnamediv>
|
||||||
@ -78,15 +78,31 @@ BEGIN [ WORK | TRANSACTION ]
|
|||||||
Description
|
Description
|
||||||
</TITLE>
|
</TITLE>
|
||||||
<para>
|
<para>
|
||||||
<command>BEGIN</command> initiates a user transaction
|
By default, <productname>Postgres</productname> executes transactions
|
||||||
which <productname>Postgres</productname> will
|
in unchained mode (also known as autocommit feature in other DBMSes).
|
||||||
guarantee is serializable with respect to all concurrently
|
In other words, each user statement is executed in its own transaction
|
||||||
executing transactions. <productname>Postgres</productname> uses two-phase
|
and commit is implicit (if execution was successfull).
|
||||||
locking
|
<command>BEGIN</command> initiates a user transaction in chained mode,
|
||||||
to perform this task. If the transaction is committed,
|
i.e. all user statements after <command>BEGIN</command> command will
|
||||||
<productname>Postgres</productname> will ensure either that all updates are
|
be executed in single transaction untill explicit COMMIT, ROLLBACK
|
||||||
done or else
|
or execution abort. Statements in chained mode are executed much faster,
|
||||||
that none of
|
because of transaction start/commit requires significant CPU and disk
|
||||||
|
activity. This mode is also required for consistency when changing
|
||||||
|
one of related tables.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Default transaction isolation level in <productname>Postgres</productname>
|
||||||
|
is READ COMMITTED one, when queries inside transaction see only changes
|
||||||
|
committed before query execution. So, you have to use
|
||||||
|
<command>SET TRANSACTION ISOLATION LEVEL SERIALIZABLE</command>
|
||||||
|
command just after BEGIN if you need in better transaction isolation.
|
||||||
|
In SERIALIZABLE mode queries will see only changes committed before entire
|
||||||
|
transaction began (actually, before execution of first DML statement
|
||||||
|
in serializable transaction).
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
If the transaction is committed, <productname>Postgres</productname>
|
||||||
|
will ensure either that all updates are done or else that none of
|
||||||
them are done. Transactions have the standard ACID
|
them are done. Transactions have the standard ACID
|
||||||
(atomic, consistent, isolatable, and durable) property.
|
(atomic, consistent, isolatable, and durable) property.
|
||||||
</para>
|
</para>
|
||||||
@ -144,9 +160,12 @@ BEGIN WORK;
|
|||||||
</TITLE>
|
</TITLE>
|
||||||
<PARA>
|
<PARA>
|
||||||
There is no explicit BEGIN WORK command in <acronym>SQL92</acronym>;
|
There is no explicit BEGIN WORK command in <acronym>SQL92</acronym>;
|
||||||
transaction initiation
|
transaction initiation is always implicit and it terminates either
|
||||||
is always implicit and it terminates either with a COMMIT or with
|
with a COMMIT or with a ROLLBACK statement.
|
||||||
a ROLLBACK statement.
|
</PARA>
|
||||||
|
<PARA>
|
||||||
|
<acronym>SQL92</acronym> also requires SERIALIZABLE to be default
|
||||||
|
transaction isolation level.
|
||||||
</PARA>
|
</PARA>
|
||||||
</refsect2>
|
</refsect2>
|
||||||
</refsect1>
|
</refsect1>
|
||||||
|
Loading…
Reference in New Issue
Block a user