Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d9fVD-0007V1-IT for pgsql-admin@arkaria.postgresql.org; Sat, 13 May 2017 22:27:07 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1d9fVD-00057c-5I for pgsql-admin@arkaria.postgresql.org; Sat, 13 May 2017 22:27:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d9fVB-00055L-Bk; Sat, 13 May 2017 22:27:05 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d9fV7-0003hr-Bz; Sat, 13 May 2017 22:27:04 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E9C5920936; Sat, 13 May 2017 18:26:57 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sat, 13 May 2017 18:26:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=NT1smXU8QOq6H4BFRR JP7Zf1je1tgiKkLEkp1YEbq7Y=; b=U0KVLTe1SVs1ffsPURKboxj91tLypSJe53 C1Zq4Bjx6eCgnKFThgRGM2mB39kfgom3LNlbXTQtlWA8W1WTuzUqDCPs7F2At546 hjpEjjG8bP1O/uIb/NzP7kUInrgoQgSowXKVlBUrWMiqucsWOQ1DfUWvo3sIBnnU ofmqrosaZ+yRnDlPxAJCbcALCta03oPfnqDL+QAZa5nhYsa4QNzyRPLqVAdUNtFs GhT6Zj4rfqfaAm6gSX/Rsvxagn4lnKFHOqEfHpdrqml/iHjFPTpknHhVEmMfXvLY 72appj2h46knwuWz3rspqNE8u39O2DMrLLvJOQvBs/TzVJpCd0Ag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=NT1smXU8QOq6H4BFRRJP7Zf1je1tgiKkLEkp1YEbq7Y=; b=NmX35VYY luu25xxfuBFLdAPSJvE80WO/bgVXvDgPesUtuUuycfG2UHNw7IVpj9M/fg72SPdl 3aFZHiSh7r9AIO+bDzP+LfTKx/IoaCPxAClTC79jx9J6eU7foxBd3vjDTonsrcKr m9l68eAOK9UZ946VY1020m8KO0CIJBH/wzG1mGl+MnLYQTBsgGfOMZpur/haOcqi h3hWwWPBG1YaC0q1IkBr92/FpmMe7PkxeEs9FYsWPa6BMbQQ/gNv3s4dWNezYkTT Xj3Ado1zNVd+B8346cTbONEJwqshNG8Ywi2u97hbF3VdshV7byZpr+5aQEVhwtPe 4uNm4wqj6abitA== X-ME-Sender: X-Sasl-enc: acEooY6QNHa8UqhmsHdkril9JjRW0BPh+pJ7zi7bD0XQ 1494714417 Received: from [192.168.1.2] (97-126-85-89.tukw.qwest.net [97.126.85.89]) by mail.messagingengine.com (Postfix) with ESMTPA id 44B0224926; Sat, 13 May 2017 18:26:57 -0400 (EDT) Subject: Re: [SQL] PostgreSQL 9.3 DB initialization issue To: Steve Midgley Cc: Ashish Tiwari , pgsql-admin@postgresql.org, postgres list References: <9e6bc162-5082-fd56-fab0-152989e4c002@aklaver.com> <727a25d0-00ab-15c3-9eff-1ec7b8e3588f@aklaver.com> From: Adrian Klaver Message-ID: <79f8f2b6-f78c-f5a9-1a90-e757d1311dcd@aklaver.com> Date: Sat, 13 May 2017 15:26:56 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.7 (--) 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 On 05/13/2017 02:50 PM, Steve Midgley wrote: > > > > I am by no means an expert on any of this, but Adrian, I think you have > a typo in your instructions? Should it read: > > "use the *[9.2]* pg_dumpall to dump the 9.2 data and then the 9.3 > pg_restore to restore it into the 9.3 instance." (in the original it > said [9.3] where my brackets are). > > I think you meant to say that v 9.2 server binary should be used to call > pg_dumpall (and run against the v9.2 running server instance), and then > the resulting dump file can be read into the 9.3 server by using the > v9.3 binary for pg_restore. The pg_restore (v9.3) command will operate > using source files created by pg_dumpall, and load that into 9.3 running > server instance. Well pg_dump(all) is backwards compatible, so the 9.3 version can dump Postgres versions going back to 7.0. I have always been told that using the newer binary against an older server is better as it will 'know' about changes in the newer version: https://www.postgresql.org/docs/9.3/static/upgrading.html 17.6.1. Upgrading Data via pg_dump "It is recommended that you use the pg_dump and pg_dumpall programs from the newer version of PostgreSQL, to take advantage of enhancements that might have been made in these programs. Current releases of the dump programs can read data from any server version back to 7.0." That being said, given that it is only a single version jump using the 9.2 version of pg_dump(all) will most likely work without a hitch. > > If I'm wrong about this, please correct me. But given the context of > debugging on this email thread, it seemed like I should point this > (possible) typo out, so there was no ambiguity for Ashish and his team. > > Steve -- Adrian Klaver adrian.klaver@aklaver.com -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin