docs: Remove notes about incompatibilies with very old versions.

These are old enough that they'll cause more confusion and distraction
to new readers, than they could help anyone upgrade from very old
servers.

Discussion: https://www.postgresql.org/message-id/fd93f1c5-7818-a02c-01e5-1075ac0d4def%40iki.fi

doc/src/sgml/func.sgml

@@ -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>

doc/src/sgml/high-availability.sgml

@@ -1632,42 +1632,6 @@ if (!triggered)
     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 &mdash;
-    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">

doc/src/sgml/indexam.sgml

@@ -368,7 +368,6 @@ amvacuumcleanup (IndexVacuumInfo *info,
   </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

doc/src/sgml/installation.sgml

@@ -560,9 +560,6 @@ build-postgresql:
     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>

doc/src/sgml/pgfreespacemap.sgml

@@ -68,13 +68,6 @@
    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>

doc/src/sgml/ref/pg_dumpall.sgml

@@ -375,10 +375,7 @@ PostgreSQL documentation
         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>