index c99499e52bdba2fdde2f051d5aa1d8a00f7e7abf..f7f401b534c7df30682efe1e1b250386cbe0c5d3 100644 (file)
@@ -6848,30 +6848,6 @@ SELECT regexp_match('abc01234xyz', '(?:(.*?)(\d+)(.*)){1,1}');
constraints, and the longest/shortest-match (rather than first-match)
matching semantics.
</para>
-
- <para>
- Two significant incompatibilities exist between AREs and the ERE syntax
- recognized by pre-7.4 releases of <productname>PostgreSQL</productname>:
-
- <itemizedlist>
- <listitem>
- <para>
- In AREs, <literal>\</literal> followed by an alphanumeric character is either
- an escape or an error, while in previous releases, it was just another
- way of writing the alphanumeric.
- This should not be much of a problem because there was no reason to
- write such a sequence in earlier releases.
- </para>
- </listitem>
- <listitem>
- <para>
- In AREs, <literal>\</literal> remains a special character within
- <literal>[]</literal>, so a literal <literal>\</literal> within a bracket
- expression must be written <literal>\\</literal>.
- </para>
- </listitem>
- </itemizedlist>
- </para>
</sect3>
<sect3 id="posix-basic-regexes">
@@ -17106,16 +17082,6 @@ nextval('foo') <lineannotation>searches search path for <literal>fo
</para>
<note>
- <para>
- Before <productname>PostgreSQL</productname> 8.1, the arguments of the
- sequence functions were of type <type>text</type>, not <type>regclass</type>, and
- the above-described conversion from a text string to an OID value would
- happen at run time during each call. For backward compatibility, this
- facility still exists, but internally it is now handled as an implicit
- coercion from <type>text</type> to <type>regclass</type> before the function is
- invoked.
- </para>
-
<para>
When you write the argument of a sequence function as an unadorned
literal string, it becomes a constant of type <type>regclass</type>.
@@ -17129,9 +17095,6 @@ nextval('foo') <lineannotation>searches search path for <literal>fo
<programlisting>
nextval('foo'::text) <lineannotation><literal>foo</literal> is looked up at runtime</lineannotation>
</programlisting>
- Note that late binding was the only behavior supported in
- <productname>PostgreSQL</productname> releases before 8.1, so you
- might need to do this to preserve the semantics of old applications.
</para>
<para>
index 339ed38d42c810a9afe18f205076f3b60ff68002..19d7bd2b28faa3c30cb8ba204e58ff1178a5b97e 100644 (file)
improvement in server robustness, nor would it be described as HA.
</para>
</sect2>
-
- <sect2 id="warm-standby-record">
- <title>Record-Based Log Shipping</title>
-
- <para>
- It is also possible to implement record-based log shipping using this
- alternative method, though this requires custom development, and changes
- will still only become visible to hot standby queries after a full WAL
- file has been shipped.
- </para>
-
- <para>
- An external program can call the <function>pg_walfile_name_offset()</function>
- function (see <xref linkend="functions-admin"/>)
- to find out the file name and the exact byte offset within it of
- the current end of WAL. It can then access the WAL file directly
- and copy the data from the last known end of WAL through the current end
- over to the standby servers. With this approach, the window for data
- loss is the polling cycle time of the copying program, which can be very
- small, and there is no wasted bandwidth from forcing partially-used
- segment files to be archived. Note that the standby servers'
- <varname>restore_command</varname> scripts can only deal with whole WAL files,
- so the incrementally copied data is not ordinarily made available to
- the standby servers. It is of use only when the primary dies —
- then the last partial WAL file is fed to the standby before allowing
- it to come up. The correct implementation of this process requires
- cooperation of the <varname>restore_command</varname> script with the data
- copying program.
- </para>
-
- <para>
- Starting with <productname>PostgreSQL</productname> version 9.0, you can use
- streaming replication (see <xref linkend="streaming-replication"/>) to
- achieve the same benefits with less effort.
- </para>
- </sect2>
</sect1>
<sect1 id="hot-standby">
index 649020b7daa2281d2718a49f9c2ee5bed3fe05a9..80473e0f1a2b0702ae00a9e01f82608b27cc6ea5 100644 (file)
</para>
<para>
- As of <productname>PostgreSQL</productname> 8.4,
<function>amvacuumcleanup</function> will also be called at completion of an
<command>ANALYZE</command> operation. In this case <literal>stats</literal> is always
NULL and any return value will be ignored. This case can be distinguished
index 3ac588dfb5c91144d7ead0709ad869919f975235..0ac1cb999992f18f3282097389d3480a14734d61 100644 (file)
The standard installation provides all the header files needed for client
application development as well as for server-side program
development, such as custom functions or data types written in C.
- (Prior to <productname>PostgreSQL</productname> 8.0, a separate <literal>make
- install-all-headers</literal> command was needed for the latter, but this
- step has been folded into the standard install.)
</para>
<formalpara>
index 0122d278e39e7b41b0b811f6cdeef8e45c6538c2..5025498249d87267101643b26d3a1ecbb75603f6 100644 (file)
space within pages. Therefore, the values are not meaningful, just
whether a page is full or empty.
</para>
-
- <note>
- <para>
- The interface was changed in version 8.4, to reflect the new FSM
- implementation introduced in the same version.
- </para>
- </note>
</sect2>
<sect2>
index 4360b2cf5773a7d5b6725e77e81e0f8519e5585d..87496430921866aba4b73bacf7d522026c6b8f7d 100644 (file)
the dump. Instead, fail if unable to lock a table within the specified
<replaceable class="parameter">timeout</replaceable>. The timeout may be
specified in any of the formats accepted by <command>SET
- statement_timeout</command>. Allowed values vary depending on the server
- version you are dumping from, but an integer number of milliseconds
- is accepted by all versions since 7.3. This option is ignored when
- dumping from a pre-7.3 server.
+ statement_timeout</command>.
</para>
</listitem>
</varlistentry>