has a new major version number for this release, which may require
recompilation of client code in certain cases.
</para>
</sect2>
...
...
@@ -2312,8 +2315,8 @@ DROP SCHEMA information_schema CASCADE;
<term>Drop Column</term>
<listitem>
<para>
PostgreSQL now supports the <literal>ALTER TABLE ... DROP
COLUMN</literal> functionality.
<productname>PostgreSQL</productname> now supports the
<literal>ALTER TABLE ... DROP COLUMN</literal> functionality.
</para>
</listitem>
</varlistentry>
...
...
@@ -2336,8 +2339,8 @@ DROP SCHEMA information_schema CASCADE;
<term>Prepared Queries</term>
<listitem>
<para>
PostgreSQL now supports prepared queries, for improved
performance.
<productname>PostgreSQL</productname> now supports prepared
queries, for improved performance.
</para>
</listitem>
</varlistentry>
...
...
@@ -2346,11 +2349,11 @@ DROP SCHEMA information_schema CASCADE;
<term>Dependency Tracking</term>
<listitem>
<para>
PostgreSQL now records object dependencies, which allows
improvements in many areas. <command>DROP</command>
statements now take either <literal>CASCADE</> or
<literal>RESTRICT</> to control whether dependent objects are
also dropped.
<productname>PostgreSQL</productname> now records object
dependencies, which allows improvements in many areas.
<command>DROP</command> statements now take either
<literal>CASCADE</> or <literal>RESTRICT</> to control whether
dependent objects are also dropped.
</para>
</listitem>
</varlistentry>
...
...
@@ -2530,7 +2533,7 @@ DROP SCHEMA information_schema CASCADE;
<itemizedlist>
<listitem><para>Add pg_locks view to show locks (Neil)</para></listitem>
<listitem><para>Security fixes for password negotiation memory allocation (Neil)</para></listitem>
<listitem><para>Remove support for version 0 FE/BE protocol (PostgreSQL 6.2 and earlier) (Tom)</para></listitem>
<listitem><para>Remove support for version 0 FE/BE protocol (<productname>PostgreSQL</productname> 6.2 and earlier) (Tom)</para></listitem>
<listitem><para>Reserve the last few backend slots for superusers, add parameter superuser_reserved_connections to control this (Nigel J. Andrews)</para></listitem>
</itemizedlist>
</sect3>
...
...
@@ -3771,7 +3774,7 @@ Python fixes (Darcy)
<para>
This release focuses on removing limitations that have existed in the
PostgreSQL code for many years.
<productname>PostgreSQL</productname> code for many years.
</para>
<para>
...
...
@@ -3784,12 +3787,12 @@ Python fixes (Darcy)
</term>
<listitem>
<para>
To maintain database consistency in case
of an operating system crash, previous releases of PostgreSQL have
forced all data modifications to disk before each transaction commit.
With WAL, only one log file must be flushed to disk, greatly improving
performance. If you have been using -F in previous releases to disable
disk flushes, you may want to consider discontinuing its use.
To maintain database consistency in case of an operating system crash,
previous releases of <productname>PostgreSQL</productname> have forced
all data modifications to disk before each transaction commit. With
WAL, only one log file must be flushed to disk, greatly improving
performance. If you have been using -F in previous releases to
disable disk flushes, you may want to consider discontinuing its use.
</para>
</listitem>
</varlistentry>
...
...
@@ -4862,17 +4865,18 @@ Add Win1250 (Czech) support (Pavel Behal)
</term>
<listitem>
<para>
This removes our old
table-level locking, and replaces it with a locking system that is
superior to most commercial database systems. In a traditional system,
each row that is modified is locked until committed, preventing reads by
other users. MVCC uses the natural multiversion nature of PostgreSQL
to allow readers to continue reading consistent data during writer
activity. Writers continue to use the compact pg_log transaction
system. This is all performed without having to allocate a lock for
every row like traditional database systems. So, basically, we no
longer are restricted by simple table-level locking;
we have something better than row-level locking.
This removes our old table-level locking, and replaces it with
a locking system that is superior to most commercial database
systems. In a traditional system, each row that is modified
is locked until committed, preventing reads by other users.
MVCC uses the natural multiversion nature of
<productname>PostgreSQL</productname> to allow readers to
continue reading consistent data during writer activity.
Writers continue to use the compact pg_log transaction system.
This is all performed without having to allocate a lock for
every row like traditional database systems. So, basically,
we no longer are restricted by simple table-level locking; we
have something better than row-level locking.
</para>
</listitem>
</varlistentry>
...
...
@@ -4933,9 +4937,10 @@ Add Win1250 (Czech) support (Pavel Behal)
</term>
<listitem>
<para>
We continue to speed up PostgreSQL, thanks to the variety of
talents within our team. We have sped up memory allocation,
optimization, table joins, and row transfer routines.
We continue to speed up <productname>PostgreSQL</productname>,
thanks to the variety of talents within our team. We have
sped up memory allocation, optimization, table joins, and row
