|
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