pg_upgrade 9.0 -> 9.3 general questions : things to watch out for - Mailing list pgsql-admin

From Achilleas Mantzios
Subject pg_upgrade 9.0 -> 9.3 general questions : things to watch out for
Date
Msg-id 567A510A.1070903@matrix.gatewaynet.com
Whole thread Raw
Responses Re: pg_upgrade 9.0 -> 9.3 general questions : things to watch out for
List pgsql-admin
Hello List,

We just finished a test upgrade using pg_upgrade from 9.0 to 9.3, and the experience has been unexpectedly good! The
databaseis just a tad smaller than 1TB, and the upgrade last only seconds, using  
the --link option.
I noticed that :
- Database specific options were correctly retained (e.g. bytea_output)
- Next XID was correctly transferred to the new cluster
I'd like to ask, if we can rely on the above assumptions during the actual migration on the production system.

Another consideration is --check. I didn't run it on the test system. Is it a requirement? A plus? The doc says about
usingit in conjunction with --link to do enable link-mode-specific checks. What  
does this do? From what I understand, running --check against the existing running older system enables doing some
checksand allowing us to perform some preparation work in parallel before the actual  
final pg_upgrade invocation. Is this true? Can anyone shed some light on this?

Another question is about --retain (I didn't use it either in our test). I understand that it might transfer or make
thelinks to the old pg_log directory. The doc says "retain SQL and *log* files  
*even* after a successful completion". What's the logic behind it? Why a special note on successful completion? If SQL
logsare the regular pg_log files, then which are the other *log* files the doc  
mentions? Apparently it cannot be WAL (pg_xlog), since this is a different format than the old version, and would be of
nouse in the new data cluster, just like the older PITR archived WALs. So,  
what's the best practice regarding regular postgresql log file and pg_uprage? How about pg_xlog? Should we just scrap
theold ones, move the new ones to the correct locations and re regenerate the  
symlinks ? Sounds fair, I think.

--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt



pgsql-admin by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [PERFORM] Connections "Startup"
Next
From: Scott Neville
Date:
Subject: Slow planning time