|
143 | 143 | </para> |
144 | 144 | </listitem> |
145 | 145 | </varlistentry> |
| 146 | + |
| 147 | + <varlistentry> |
| 148 | + <term> |
| 149 | + serialization anomaly |
| 150 | + <indexterm><primary>serialization anomaly</primary></indexterm> |
| 151 | + </term> |
| 152 | + <listitem> |
| 153 | + <para> |
| 154 | + The result of successfully committing a group of transactions |
| 155 | + is inconsistent with all possible orderings of running those |
| 156 | + transactions one at a time. |
| 157 | + </para> |
| 158 | + </listitem> |
| 159 | + </varlistentry> |
146 | 160 | </variablelist> |
147 | 161 | </para> |
148 | 162 |
|
149 | 163 | <para> |
150 | 164 | <indexterm> |
151 | 165 | <primary>transaction isolation level</primary> |
152 | 166 | </indexterm> |
153 | | - Thefour transaction isolation levels and the corresponding |
154 | | -behaviorsare described in <xref linkend="mvcc-isolevel-table">. |
| 167 | + TheSQL standard and PostgreSQL-implemented transaction isolation levels |
| 168 | + are described in <xref linkend="mvcc-isolevel-table">. |
155 | 169 | </para> |
156 | 170 |
|
157 | 171 | <table tocentry="1" id="mvcc-isolevel-table"> |
158 | | - <title>Standard <acronym>SQL</acronym>Transaction Isolation Levels</title> |
159 | | - <tgroup cols="4"> |
| 172 | + <title>Transaction Isolation Levels</title> |
| 173 | + <tgroup cols="5"> |
160 | 174 | <thead> |
161 | 175 | <row> |
162 | 176 | <entry> |
|
171 | 185 | <entry> |
172 | 186 | Phantom Read |
173 | 187 | </entry> |
| 188 | + <entry> |
| 189 | + Serialization Anomaly |
| 190 | + </entry> |
174 | 191 | </row> |
175 | 192 | </thead> |
176 | 193 | <tbody> |
177 | 194 | <row> |
178 | 195 | <entry> |
179 | 196 | Read uncommitted |
180 | 197 | </entry> |
| 198 | + <entry> |
| 199 | + Allowed, but not in PG |
| 200 | + </entry> |
181 | 201 | <entry> |
182 | 202 | Possible |
183 | 203 | </entry> |
|
202 | 222 | <entry> |
203 | 223 | Possible |
204 | 224 | </entry> |
| 225 | + <entry> |
| 226 | + Possible |
| 227 | + </entry> |
205 | 228 | </row> |
206 | 229 |
|
207 | 230 | <row> |
|
214 | 237 | <entry> |
215 | 238 | Not possible |
216 | 239 | </entry> |
| 240 | + <entry> |
| 241 | + Allowed, but not in PG |
| 242 | + </entry> |
217 | 243 | <entry> |
218 | 244 | Possible |
219 | 245 | </entry> |
|
232 | 258 | <entry> |
233 | 259 | Not possible |
234 | 260 | </entry> |
| 261 | + <entry> |
| 262 | + Not possible |
| 263 | + </entry> |
235 | 264 | </row> |
236 | 265 | </tbody> |
237 | 266 | </tgroup> |
238 | 267 | </table> |
239 | 268 |
|
240 | 269 | <para> |
241 | | - In <productname>PostgreSQL</productname>, you can request any of the |
242 | | - four standard transaction isolation levels. Butinternally, there are |
243 | | -onlythree distinct isolation levels, which correspond to the levels Read |
244 | | -Committed, RepeatableRead, and Serializable. When you select the level Read |
245 | | -Uncommitted you really get Read Committed, and phantom reads are not possible |
246 | | -in the <productname>PostgreSQL</productname> implementation of Repeatable |
247 | | - Read, so the actual |
248 | | - isolation level might be stricter than what you select. This is |
249 | | - permitted by the SQL standard: the four isolation levels only |
250 | | -define which phenomena must not happen, they do not define which |
251 | | -phenomena must happen.The reason that <productname>PostgreSQL</> |
252 | | -only provides threeisolation levelsis that this is the only |
253 | | -sensible way to map the standard isolation levels to the multiversion |
254 | | -concurrency control architecture.The behavior of the available |
255 | | -isolation levels is detailed in thefollowing subsections. |
| 270 | + In <productname>PostgreSQL</productname>, you can request any of |
| 271 | +thefour standard transaction isolation levels, butinternally only |
| 272 | + three distinct isolation levels are implemented, i.e. PostgreSQL's |
| 273 | + Read Uncommitted mode behaves like Read Committed. This is because |
| 274 | +it is the only sensible way to map the standard isolation levels to |
| 275 | + PostgreSQL's multiversion concurrency control architecture. |
| 276 | +</para> |
| 277 | + |
| 278 | +<para> |
| 279 | +The table also shows that PostgreSQL's Repeatable Read implementation |
| 280 | +does not allow phantom reads.Stricter behavior is permitted by the |
| 281 | +SQL standard: the fourisolation levelsonly define which phenomena |
| 282 | +must not happen, not which phenomena <emphasis>must</> happen. |
| 283 | + The behavior of the available isolation levels is detailed in the |
| 284 | + following subsections. |
256 | 285 | </para> |
257 | 286 |
|
258 | 287 | <para> |
|