10
10
BEGIN WORK
11
11
</REFNAME>
12
12
<REFPURPOSE>
13
- Begins a transaction
13
+ Begins a transaction in chained mode
14
14
</REFPURPOSE>
15
15
16
16
</refnamediv>
@@ -78,15 +78,31 @@ BEGIN [ WORK | TRANSACTION ]
78
78
Description
79
79
</TITLE>
80
80
<para>
81
- <command>BEGIN</command> initiates a user transaction
82
- which <productname>Postgres</productname> will
83
- guarantee is serializable with respect to all concurrently
84
- executing transactions. <productname>Postgres</productname> uses two-phase
85
- locking
86
- to perform this task. If the transaction is committed,
87
- <productname>Postgres</productname> will ensure either that all updates are
88
- done or else
89
- that none of
81
+ By default, <productname>Postgres</productname> executes transactions
82
+ in unchained mode (also known as autocommit feature in other DBMSes).
83
+ In other words, each user statement is executed in its own transaction
84
+ and commit is implicit (if execution was successfull).
85
+ <command>BEGIN</command> initiates a user transaction in chained mode,
86
+ i.e. all user statements after <command>BEGIN</command> command will
87
+ be executed in single transaction untill explicit COMMIT, ROLLBACK
88
+ or execution abort. Statements in chained mode are executed much faster,
89
+ because of transaction start/commit requires significant CPU and disk
90
+ activity. This mode is also required for consistency when changing
91
+ one of related tables.
92
+ </para>
93
+ <para>
94
+ Default transaction isolation level in <productname>Postgres</productname>
95
+ is READ COMMITTED one, when queries inside transaction see only changes
96
+ committed before query execution. So, you have to use
97
+ <command>SET TRANSACTION ISOLATION LEVEL SERIALIZABLE</command>
98
+ command just after BEGIN if you need in better transaction isolation.
99
+ In SERIALIZABLE mode queries will see only changes committed before entire
100
+ transaction began (actually, before execution of first DML statement
101
+ in serializable transaction).
102
+ </para>
103
+ <para>
104
+ If the transaction is committed, <productname>Postgres</productname>
105
+ will ensure either that all updates are done or else that none of
90
106
them are done. Transactions have the standard ACID
91
107
(atomic, consistent, isolatable, and durable) property.
92
108
</para>
@@ -105,12 +121,12 @@ BEGIN [ WORK | TRANSACTION ]
105
121
106
122
<PARA>
107
123
Refer to the <command>LOCK</command> statement for further information
108
- about locking tables inside a transaction.
124
+ about locking tables inside a transaction.
109
125
</PARA>
110
126
111
127
<PARA>
112
128
Use <command>COMMIT</command> or <command>ROLLBACK</command>
113
- to terminate a transaction.
129
+ to terminate a transaction.
114
130
</PARA>
115
131
</REFSECT2>
116
132
</refsect1>
@@ -133,7 +149,7 @@ BEGIN WORK;
133
149
</TITLE>
134
150
<PARA>
135
151
<command>BEGIN</command>
136
- is a <productname>Postgres</productname> language extension.
152
+ is a <productname>Postgres</productname> language extension.
137
153
</para>
138
154
<REFSECT2 ID="R2-SQL-BEGINWORK-4">
139
155
<REFSECT2INFO>
@@ -144,9 +160,12 @@ BEGIN WORK;
144
160
</TITLE>
145
161
<PARA>
146
162
There is no explicit BEGIN WORK command in <acronym>SQL92</acronym>;
147
- transaction initiation
148
- is always implicit and it terminates either with a COMMIT or with
149
- a ROLLBACK statement.
163
+ transaction initiation is always implicit and it terminates either
164
+ with a COMMIT or with a ROLLBACK statement.
165
+ </PARA>
166
+ <PARA>
167
+ <acronym>SQL92</acronym> also requires SERIALIZABLE to be default
168
+ transaction isolation level.
150
169
</PARA>
151
170
</refsect2>
152
171
</refsect1>
0 commit comments