Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 83be50d

Browse files
committed
docs: clarify pg_upgrade's recovery behavior
The previous paragraph trying to explain --check, --link, and no --link modes and the various points of failure was too complex. Instead, use bullet lists and sublists. Reported-by: Daniel Gustafsson Discussion: https://postgr.es/m/qtqiv7hI87s_Xvz5ZXHCaH-1-_AZGpIDJowzlRjF3-AbCr3RhSNydM_JCuJ8DE4WZozrtxhIWmyYTbv0syKyfGB6cYMQitp9yN-NZMm-oAo=@yesql.se Backpatch-through: 9.4
1 parent 7e5569f commit 83be50d

File tree

1 file changed

+36
-16
lines changed

1 file changed

+36
-16
lines changed

doc/src/sgml/ref/pgupgrade.sgml

Lines changed: 36 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -643,32 +643,52 @@ psql --username=postgres --file=script.sql postgres
643643
<itemizedlist>
644644
<listitem>
645645
<para>
646-
If you ran <command>pg_upgrade</command>
647-
with <option>--check</option>, no modifications were made to the old
648-
cluster and you can re-use it anytime.
646+
If the <option>--check</option> option was used, the old cluster
647+
was unmodified; it can be restarted.
649648
</para>
650649
</listitem>
651650

652651
<listitem>
653652
<para>
654-
If you ran <command>pg_upgrade</command>
655-
with <option>--link</option>, the data files are shared between the
656-
old and new cluster. If you started the new cluster, the new
657-
server has written to those shared files and it is unsafe to
658-
use the old cluster.
653+
If the <option>--link</option> option was <emphasis>not</emphasis>
654+
used, the old cluster was unmodified; it can be restarted.
659655
</para>
660656
</listitem>
661657

662658
<listitem>
663659
<para>
664-
If you ran <command>pg_upgrade</command> <emphasis>without</emphasis>
665-
<option>--link</option> or did not start the new server, the
666-
old cluster was not modified except that, if linking
667-
started, a <literal>.old</literal> suffix was appended to
668-
<filename>$PGDATA/global/pg_control</filename>. To reuse the old
669-
cluster, possibly remove the <filename>.old</filename> suffix from
670-
<filename>$PGDATA/global/pg_control</filename>; you can then restart the
671-
old cluster.
660+
If the <option>--link</option> option was used, the data
661+
files might be shared between the old and new cluster:
662+
663+
<itemizedlist>
664+
<listitem>
665+
<para>
666+
If <command>pg_upgrade</command> aborted before linking started,
667+
the old cluster was unmodified; it can be restarted.
668+
</para>
669+
</listitem>
670+
671+
<listitem>
672+
<para>
673+
If you did <emphasis>not</emphasis> start the new cluster, the old
674+
cluster was unmodified except that, when linking started, a
675+
<literal>.old</literal> suffix was appended to
676+
<filename>$PGDATA/global/pg_control</filename>. To reuse the old
677+
cluster, remove the <filename>.old</filename> suffix from
678+
<filename>$PGDATA/global/pg_control</filename>; you can then restart
679+
the old cluster.
680+
</para>
681+
</listitem>
682+
683+
<listitem>
684+
<para>
685+
If you did start the new cluster, it has written to shared files
686+
and it is unsafe to use the old cluster. The old cluster will
687+
need to be restored from backup in this case.
688+
</para>
689+
</listitem>
690+
691+
</itemizedlist>
672692
</para>
673693
</listitem>
674694
</itemizedlist>

0 commit comments

Comments
 (0)