Skip to content

Commit cb7dad1

Browse files
author
Thomas G. Lockhart
committed
Make separate subsection for Vadim's MVCC notes.
Add timing info for v6.5 on my linux box.
1 parent 29af124 commit cb7dad1

File tree

1 file changed

+100
-64
lines changed

1 file changed

+100
-64
lines changed

‎doc/src/sgml/release.sgml

Lines changed: 100 additions & 64 deletions
Original file line numberDiff line numberDiff line change
@@ -39,9 +39,10 @@
3939
other users. MVCC uses the natural multi-version nature of PostgreSQL
4040
to allow readers to continue reading consistent data during writer
4141
activity. Writers continue to use the compact pg_log transaction
42-
system. This is all preformed without having to allocate a lock for
42+
system. This is all performed without having to allocate a lock for
4343
every row like traditional database systems. So, basically, we no
44-
longer have table-level locking, we have something better than row-level
44+
longer are restricted by simple table-level locking;
45+
we have something better than row-level
4546
locking.
4647
</para>
4748
</listitem>
@@ -134,59 +135,61 @@
134135
</para>
135136

136137
<para>
137-
138-
Because readers in 6.5 don't lock data, regardless of transaction
139-
isolation level, data read by one transaction can be overwritten by
140-
another. In the other words, if a row is returned by
141-
<command>SELECT</command> it doesn't mean that this row really exists
142-
at the time it is returned (i.e. sometime after the statement or
143-
transaction began) nor that the row is protected from deletion or
144-
updation by concurrent transactions before the current transaction does
145-
a commit or rollback.
146-
147-
</para>
148-
149-
<para>
150-
151-
To ensure the actual existance of a row and protect it against
152-
concurrent updates one must use <command>SELECT FOR UPDATE</command> or
153-
an appropriate <command>LOCK TABLE</command> statement. This should be
154-
taken into account when porting applications from previous releases of
155-
<productname>Postgres</productname> and other environments.
156-
157-
</para>
158-
159-
<para>
160-
161-
Keep above in mind if you are using contrib/refint.* triggers for
162-
referential integrity. Additional technics are required now. One way is
163-
to use <command>LOCK parent_table IN SHARE ROW EXCLUSIVE MODE</command>
164-
command if a transaction is going to update/delete a primary key and
165-
use <command>LOCK parent_table IN SHARE MODE</command> command if a
166-
transaction is going to update/insert a foreign key.
167-
168-
<note>
169-
<para>
170-
171-
Note that if you run a transaction in SERIALIZABLE mode then you must
172-
execute <command>LOCK</command> commands above before execution of any
173-
DML statement
174-
(<command>SELECT/INSERT/DELETE/UPDATE/FETCH/COPY_TO</command>) in the
175-
transaction.
176-
177-
</para>
178-
</note>
179-
180-
<para>
181-
182-
These inconveniences will disappear when the ability to read durty
183-
(uncommitted) data, regardless of isolation level, and true referential
184-
integrity will be implemented.
185-
186-
</para>
187-
138+
The new Multi-Version Concurrency Control (MVCC) features can
139+
give somewhat different behaviors in multi-user
140+
environments. <emphasis>Read and understand the following section
141+
to ensure that your existing applications will give you the
142+
behavior you need.</emphasis>
188143
</para>
189144

145+
<sect3>
146+
<title>Multi-Version Concurrency Control</title>
147+
148+
<para>
149+
Because readers in 6.5 don't lock data, regardless of transaction
150+
isolation level, data read by one transaction can be overwritten by
151+
another. In the other words, if a row is returned by
152+
<command>SELECT</command> it doesn't mean that this row really exists
153+
at the time it is returned (i.e. sometime after the statement or
154+
transaction began) nor that the row is protected from deletion or
155+
updation by concurrent transactions before the current transaction does
156+
a commit or rollback.
157+
</para>
158+
159+
<para>
160+
To ensure the actual existance of a row and protect it against
161+
concurrent updates one must use <command>SELECT FOR UPDATE</command> or
162+
an appropriate <command>LOCK TABLE</command> statement. This should be
163+
taken into account when porting applications from previous releases of
164+
<productname>Postgres</productname> and other environments.
165+
</para>
166+
167+
<para>
168+
Keep above in mind if you are using contrib/refint.* triggers for
169+
referential integrity. Additional technics are required now. One way is
170+
to use <command>LOCK parent_table IN SHARE ROW EXCLUSIVE MODE</command>
171+
command if a transaction is going to update/delete a primary key and
172+
use <command>LOCK parent_table IN SHARE MODE</command> command if a
173+
transaction is going to update/insert a foreign key.
174+
175+
<note>
176+
<para>
177+
Note that if you run a transaction in SERIALIZABLE mode then you must
178+
execute the <command>LOCK</command> commands above before execution of any
179+
DML statement
180+
(<command>SELECT/INSERT/DELETE/UPDATE/FETCH/COPY_TO</command>) in the
181+
transaction.
182+
</para>
183+
</note>
184+
</para>
185+
186+
<para>
187+
These inconveniences will disappear in the future
188+
when the ability to read dirty
189+
(uncommitted) data (regardless of isolation level) and true referential
190+
integrity will be implemented.
191+
</para>
192+
</sect3>
190193
</sect2>
191194

192195
<sect2>
@@ -2541,22 +2544,55 @@ Initial release.
25412544
</para>
25422545
</sect1>
25432546

2544-
<sect1>
2545-
<title>Timing Results</title>
2547+
<sect1>
2548+
<title>Timing Results</title>
25462549

2547-
<para>
2548-
These timing results are from running the regression test with the commands
2550+
<para>
2551+
These timing results are from running the regression test with the commands
25492552

2550-
<programlisting>
2553+
<programlisting>
25512554
% cd src/test/regress
25522555
% make all
25532556
% time make runtest
2554-
</programlisting>
2555-
</para>
2556-
<para>
2557-
Timing under Linux 2.0.27 seems to have a roughly 5% variation from run
2558-
to run, presumably due to the scheduling vagaries of multitasking systems.
2559-
</para>
2557+
</programlisting>
2558+
</para>
2559+
<para>
2560+
Timing under Linux 2.0.27 seems to have a roughly 5% variation from run
2561+
to run, presumably due to the scheduling vagaries of multitasking systems.
2562+
</para>
2563+
2564+
<sect2>
2565+
<title>v6.5</title>
2566+
2567+
<para>
2568+
As has been the case for previous releases, timing between
2569+
releases is not directly comparable since new regression tests
2570+
have been added. In general, v6.5 is faster than previous
2571+
releases.
2572+
</para>
2573+
2574+
<para>
2575+
Timing with <function>fsync()</function> disabled:
2576+
2577+
<programlisting>
2578+
Time System
2579+
02:00 Dual Pentium Pro 180, 224MB, UW-SCSI, Linux 2.0.36, gcc 2.7.2.3 -O2 -m486
2580+
</programlisting>
2581+
</para>
2582+
2583+
<para>
2584+
Timing with <function>fsync()</function> enabled:
2585+
2586+
<programlisting>
2587+
Time System
2588+
04:21 Dual Pentium Pro 180, 224MB, UW-SCSI, Linux 2.0.36, gcc 2.7.2.3 -O2 -m486
2589+
</programlisting>
2590+
2591+
For the linux system above, using UW-SCSI disks rather than (older) IDE
2592+
disks leads to a 50% improvement in speed on the regression test.
2593+
</para>
2594+
</sect2>
2595+
25602596
<sect2>
25612597
<title>v6.4beta</title>
25622598

0 commit comments

Comments
 (0)