DOC: updated migration instructions for postgres pro 10.2.1 release

Author: Liudmila Mantrova

doc/src/sgml/release-pro-10.sgml

@@ -90,128 +90,15 @@
   <sect2>
     <title>Migration to Version 10.2.1</title>
 
-    <para>
-      To migrate to <productname>Postgres Pro</productname> 10, you can perform a dump/restore using
-      <xref linkend="app-pg-dumpall">, or use the <xref linkend="pgupgrade"> utility.
-      The first option is safer, while the second is faster and can significantly
-      speed up the upgrade process for large databases. If you choose to run
-      <application>pg_upgrade</application>, make sure to initialize the new
-      database cluster with the same <link linkend="app-initdb-data-checksums">checksum setting</link>
-      as the database cluster you are migrating from.
-    </para>
-    
-    <para>
-       When migrating to <productname>Postgres Pro</productname> 10, do not
-       use the <filename>postgrespro-std-&majorversion;</filename>
-       package to avoid conflicts. Use the individual packages instead.
-       In this case, server autostart needs to be enabled manually, if required.
-    </para>
-    
-    <para>Starting from <productname>Postgres Pro</productname> 10, you can specify the
-      default collation provider when initializing the database cluster or
-      creating the database, as explained in <xref linkend="collation-managing">.
-      You must take it into account when upgrading to this release
-      to avoid breaking indexes and constraints.
-    </para>
-    
-    <important>
-      <para>
-        If your current <productname>Postgres Pro</productname> installation
-        uses ICU, do not update ICU library to a newer version.
-        Otherwise, you cannot upgrade to <productname>Postgres Pro</productname> 10.
-      </para>
-    </important>
-    <important>
-      <para>
-        For <productname>PostgreSQL</productname> 9.5 and 9.5.1,
-        as well as <productname>Postgres Pro</productname> 9.5.0.1 and
-        9.5.1.2, you cannot perform an upgrade to
-        <productname>Postgres Pro</productname> 10 directly. If you are
-        using one of these versions, upgrade your installation to an
-        intermediate version first, such as
-        <productname>Postgres Pro</productname> 9.5.2.1.
+    <para>If you are upgrading from a <productname>Postgres Pro</productname> version
+      based on the same <productname>PostgreSQL</productname> major release,
+      it is enough to install the new version into your current installation directory.
       </para>
-    </important>
-    
-    <para>
-      When using <xref linkend="pgupgrade">, make sure that
-      <xref linkend="APP-INITDB"> sets the correct default collation provider
-      for the new database cluster:
+    <para>To migrate from <productname>PostgreSQL</productname> or
+      <productname>Postgres Pro</productname> versions based on
+      any previous <productname>PostgreSQL</productname> major release, see the instructions
+      in <link linkend="release-pro-10-1-1">Postgres Pro 10.1.1 Release Notes</link>.
     </para>
-      <itemizedlist>
-        <listitem>
-          <para>When migrating from vanilla <productname>PostgreSQL</productname>, specify <literal>libc</>
-          as the default collation provider.
-          </para>
-        </listitem>
-        <listitem>
-          <para>When upgrading from <productname>Postgres Pro</productname>, omit
-          the default collation provider option to select the required collation
-          provider automatically. In this case, <literal>libc</literal> provider
-          will be used for databases with C and POSIX locales, as well as for all
-          databases with single-byte encodings, while <literal>icu</literal>
-          provider will be used for all the other cases.
-          </para>
-        </listitem>
-      </itemizedlist>
-      <para>If <application>pg_upgrade</application> creates any SQL files in
-          its current directory, run these files to complete the upgrade.
-      </para>
-
-      <para>
-        When you are using <xref linkend="app-pg-dumpall">
-        to perform the upgrade, <productname>Postgres Pro</productname> uses
-        the collation provider specified with the <command>initdb</command>
-        command for the new cluster. In this case, indexes are rebuilt
-        automatically. To avoid issues with collation-dependent constraints,
-        you are recommended to use <literal>libc</literal> provider when
-        upgrading from vanilla <productname>PostgreSQL</productname>, and
-        omit the provider when upgrading from a previous version of
-        <productname>Postgres Pro</productname>, unless you have databases with
-        non-C and non-POSIX collation settings. For such databases, you should
-        do the following:
-        <itemizedlist>
-          <listitem>
-            <para>If the new cluster is initialized with locales other than C or POSIX,
-            and the database has an single-byte encoding, set LC_COLLATE to '@libc' for this database.
-            </para>
-          </listitem>
-          <listitem>
-            <para>If the new cluster is initialized with C or POSIX locale settings and
-            the database has a multi-byte encoding, set LC_COLLATE to <literal>'@icu'</literal> for this database.
-            </para>
-          </listitem>
-        </itemizedlist>
-      </para>
-
-      <note>
-      <para>
-          If the previous <productname>Postgres Pro</productname> installation
-          contained any indexes or constraints depending on collations
-          other than the default collation of the database, <literal>C</literal>,
-          or <literal>POSIX</literal> in databases with multibyte encodings,
-          such databases could contain some data that violated the specified
-          constraints and made indexes inconsistent. On Windows, this situation
-          can also happen if the database with a multibyte encoding contained
-          any indexes or constraints depending on the default collation with a
-          verbose name, such as
-          <literal>"Russian_Russia[.<replaceable>encoding</replaceable>]"</literal>
-          or <literal>"English_United
-          States[.<replaceable>encoding</replaceable>]"</literal>.
-          In such cases, you can only use <application>pg_upgrade</application> to upgrade to
-          <productname>Postgres Pro</productname> 10, as a dump/restore scenario may be impossible.
-          To resolve these issues, <application>pg_upgrade</application> declares such indexes and
-          constraints invalid and creates <filename>reindex_text_indexes.sql</filename>
-          and <filename>validate_text_contraints.sql</filename>, respectively.
-       </para>
-       </note>
-
-     <para>
-       When building <productname>Postgres Pro</> manually, you must include ICU
-       using the <option>--with-icu</option> option. Otherwise, you cannot
-       upgrade to <productname>Postgres Pro</productname> 10 from a previous
-       <productname>Postgres Pro</productname> version.
-      </para>
 
   </sect2>
 </sect1>