From 8b947ab430378e38ff178e37b41906a413c5bf4a Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Wed, 17 Apr 2019 18:01:02 -0400 Subject: [PATCH] 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 --- doc/src/sgml/ref/pgupgrade.sgml | 52 +++++++++++++++++++++++---------- 1 file changed, 36 insertions(+), 16 deletions(-) diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml index 975236774f..3f284097db 100644 --- a/doc/src/sgml/ref/pgupgrade.sgml +++ b/doc/src/sgml/ref/pgupgrade.sgml @@ -643,32 +643,52 @@ psql --username=postgres --file=script.sql postgres - If you ran pg_upgrade - with option was used, the old cluster + was unmodified; it can be restarted. - If you ran pg_upgrade - with option was not + used, the old cluster was unmodified; it can be restarted. - If you ran pg_upgrade without - -- 2.40.0