Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lKIja-0000s0-HB for pgsql-admin@arkaria.postgresql.org; Thu, 11 Mar 2021 10:40:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lKIjY-0007OI-5d for pgsql-admin@arkaria.postgresql.org; Thu, 11 Mar 2021 10:40:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lKIjX-0007KZ-Kn for pgsql-admin@lists.postgresql.org; Thu, 11 Mar 2021 10:39:59 +0000 Received: from mail.pscs.co.uk ([195.224.19.137]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lKIjS-0007eK-As for pgsql-admin@lists.postgresql.org; Thu, 11 Mar 2021 10:39:57 +0000 Authentication-Results: mail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=pscs Received: from lmail.pscs.co.uk ([192.168.66.70]) by mail.pscs.co.uk ([10.224.19.137] running VPOP3) with ESMTPSA (TLSv1.3 TLS_AES_256_GCM_SHA384) for ; Thu, 11 Mar 2021 10:39:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pscs.co.uk; q=dns/txt; s=lmail; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Cc :Content-Transfer-Encoding:Reply-to:Sender; t=1615458885; x=1616063685; bh=aGUlrSWfjAQ/9uStzvqNWPJcSyUTlaNpbFPFuN2sEAk=; b=LGcjtB/Hph9l/TBYsizT6nMNPkFP2xbmSYBuRVF7fDpLSvw1C3lFpNyzGCkbcdq2ao506GYy eRnWx7KaysGt3dDuKnScIrM89DCrJr90RjyKKKFqC5kVdAhfN5In4SDVSBKHBLUeRrTKoS0b7D z/Kd24rPjFCHfMh46ZXLJqMkc= Authentication-Results: lmail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul Received: from [192.168.57.136] ([82.68.48.206] (82-68-48-206.dsl.in-addr.zen.co.uk)) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTPSA (TLSv1.3 TLS_AES_256_GCM_SHA384); Thu, 11 Mar 2021 10:34:44 -0000 To: pgsql-admin@lists.postgresql.org From: Paul Smith Subject: Using pg_upgrade to change from 32 to 64 bit. Message-ID: <33cc9b29-b14e-583e-88eb-32bc4006cc9d@pscs.co.uk> Date: Thu, 11 Mar 2021 10:34:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A791281263AE9A9214885EA0" Content-Language: en-GB X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V8.1 - Registered to: PSCS X-Organisation: Paul Smith Computer Services X-VPOP3Tester: 12 345 X-Authenticated-Sender: pscs List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------A791281263AE9A9214885EA0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, we've been using 32 bit PostgreSQL 9.5 on Windows and are seeing how we could upgrade to v13 64 bit. As far as I can see from the documentation and other discussion on the Internet, the only way to do this is to do a pg_dump and pg_restore, which could take a while with a large database. Just "for kicks" I decided to try to use pg_upgrade to do it (on a test database).  The documentation seems to suggest that it won't work "pg_upgradedoes its best to make sure the old and new clusters are binary-compatible, e.g., by checking for compatible compile-time settings, *including 32/64-bit binaries*." To my surprise, it seemed to work absolutely fine. I can start the new 64 bit cluster, and a quick check shows everything working OK. Is this to be expected? Was it a fluke? I'd expect it to refuse to work rather than claim to work and give me a broken database. -- Paul Paul Smith Computer Services support@pscs.co.uk - 01484 855800 -- Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 Sign up for news & updates at http://www.pscs.co.uk/go/subscribe --------------A791281263AE9A9214885EA0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, we've been using 32 bit PostgreSQL 9.5 on Windows and are seeing how we could upgrade to v13 64 bit.

As far as I can see from the documentation and other discussion on the Internet, the only way to do this is to do a pg_dump and pg_restore, which could take a while with a large database.

Just "for kicks" I decided to try to use pg_upgrade to do it (on a test database).  The documentation seems to suggest that it won't work

"pg_upgrade does its best to make sure the old and new clusters are binary-compatible, e.g., by checking for compatible compile-time settings, *including 32/64-bit binaries*."

To my surprise, it seemed to work absolutely fine. I can start the new 64 bit cluster, and a quick check shows everything working OK.

Is this to be expected? Was it a fluke? I'd expect it to refuse to work rather than claim to work and give me a broken database.

-- 
Paul
Paul Smith Computer Services
support@pscs.co.uk - 01484 855800

--

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

--------------A791281263AE9A9214885EA0--