Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aBe71-0006ui-Dl for pgsql-admin@arkaria.postgresql.org; Wed, 23 Dec 2015 07:45:31 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aBe70-000114-ON for pgsql-admin@arkaria.postgresql.org; Wed, 23 Dec 2015 07:45:30 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aBe6z-00010b-TW for pgsql-admin@postgresql.org; Wed, 23 Dec 2015 07:45:30 +0000 Received: from host3.dynacom.ondsl.gr ([62.103.35.211] helo=smadev.internal.net) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aBe6w-0000Uv-Kz for pgsql-admin@postgresql.org; Wed, 23 Dec 2015 07:45:28 +0000 Received: from smadev.internal.net (smadev [10.9.200.131]) by smadev.internal.net (8.15.2/8.15.2) with ESMTP id tBN7jEJd018159; Wed, 23 Dec 2015 09:45:14 +0200 (EET) (envelope-from achill@matrix.gatewaynet.com) To: pgsql-admin@postgresql.org, itdev From: Achilleas Mantzios Subject: pg_upgrade 9.0 -> 9.3 general questions : things to watch out for Message-ID: <567A510A.1070903@matrix.gatewaynet.com> Date: Wed, 23 Dec 2015 09:45:14 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org 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 database is 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 using it 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 checks and 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 the links 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 logs are 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 no use 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 the old 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 -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin