|
65 | 65 | </para>
|
66 | 66 |
|
67 | 67 | <para>
|
68 |
| - pg_upgrade supports upgrades from 8.3.X and later to the current |
| 68 | + pg_upgrade supports upgrades from 8.4.X and later to the current |
69 | 69 | major release of <productname>PostgreSQL</>, including snapshot and alpha releases.
|
70 | 70 | </para>
|
71 | 71 | </refsect1>
|
@@ -314,12 +314,7 @@ pg_ctl -D /opt/PostgreSQL/9.0 stop
|
314 | 314 | NET STOP postgresql-8.4
|
315 | 315 | NET STOP postgresql-9.0
|
316 | 316 | </programlisting>
|
317 |
| - |
318 |
| - or |
319 |
| - |
320 |
| -<programlisting> |
321 |
| -NET STOP pgsql-8.3 (<productname>PostgreSQL</> 8.3 and older used a different service name) |
322 |
| -</programlisting></para> |
| 317 | + </para> |
323 | 318 | </step>
|
324 | 319 |
|
325 | 320 | <step>
|
@@ -577,81 +572,6 @@ psql --username postgres --file script.sql postgres
|
577 | 572 | is down.
|
578 | 573 | </para>
|
579 | 574 |
|
580 |
| - <refsect2> |
581 |
| - <title>Limitations in Upgrading from PostgreSQL 8.3</title> |
582 |
| - |
583 |
| - <para> |
584 |
| - Upgrading <emphasis>from</emphasis> PostgreSQL 8.3 has additional restrictions not present |
585 |
| - when upgrading from later PostgreSQL releases. For example, |
586 |
| - pg_upgrade will not work for upgrading from 8.3 if a user column |
587 |
| - is defined as: |
588 |
| - <itemizedlist> |
589 |
| - <listitem> |
590 |
| - <para> |
591 |
| - a <type>tsquery</> data type |
592 |
| - </para> |
593 |
| - </listitem> |
594 |
| - <listitem> |
595 |
| - <para> |
596 |
| - data type <type>name</> and is not the first column |
597 |
| - </para> |
598 |
| - </listitem> |
599 |
| - </itemizedlist> |
600 |
| - </para> |
601 |
| - |
602 |
| - <para> |
603 |
| - You must drop any such columns and upgrade them manually. |
604 |
| - </para> |
605 |
| - |
606 |
| - <para> |
607 |
| - pg_upgrade will not work if the <filename>ltree</> |
608 |
| - contrib module is installed in a database. |
609 |
| - </para> |
610 |
| - |
611 |
| - <para> |
612 |
| - pg_upgrade will require a table rebuild if: |
613 |
| - <itemizedlist> |
614 |
| - <listitem> |
615 |
| - <para> |
616 |
| - a user column is of data type <type>tsvector</type> |
617 |
| - </para> |
618 |
| - </listitem> |
619 |
| - </itemizedlist> |
620 |
| - </para> |
621 |
| - |
622 |
| - <para> |
623 |
| - pg_upgrade will require a reindex if: |
624 |
| - <itemizedlist> |
625 |
| - <listitem> |
626 |
| - <para> |
627 |
| - an index is of type hash or GIN |
628 |
| - </para> |
629 |
| - </listitem> |
630 |
| - <listitem> |
631 |
| - <para> |
632 |
| - an index uses <function>bpchar_pattern_ops</> |
633 |
| - </para> |
634 |
| - </listitem> |
635 |
| - </itemizedlist> |
636 |
| - </para> |
637 |
| - |
638 |
| - <para> |
639 |
| - Also, the default datetime storage format changed to integer after |
640 |
| - <productname>PostgreSQL</> 8.3. pg_upgrade will check that the datetime storage format |
641 |
| - used by the old and new clusters match. Make sure your new cluster is |
642 |
| - built with the configure flag <option>--disable-integer-datetimes</>. |
643 |
| - </para> |
644 |
| - |
645 |
| - <para> |
646 |
| - For Windows users, note that due to different integer datetimes settings |
647 |
| - used by the graphical installer and the MSI installer, it is only |
648 |
| - possible to upgrade from version 8.3 of the installer distribution to |
649 |
| - version 8.4 or later of the installer distribution. It is not |
650 |
| - possible to upgrade from the MSI installer to the new graphical installer. |
651 |
| - </para> |
652 |
| - |
653 |
| - </refsect2> |
654 |
| - |
655 | 575 | </refsect1>
|
656 | 576 |
|
657 | 577 | <refsect1>
|
|
0 commit comments