Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDS5f-000oST-Sg for pgsql-admin@arkaria.postgresql.org; Tue, 19 Nov 2024 17:32:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tDS5d-00FKG4-St for pgsql-admin@arkaria.postgresql.org; Tue, 19 Nov 2024 17:32:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDS5d-00FKFh-Bt for pgsql-admin@lists.postgresql.org; Tue, 19 Nov 2024 17:32:37 +0000 Received: from smtp2.vianet.ca ([209.91.128.19]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDS5a-002mnI-IG for pgsql-admin@lists.postgresql.org; Tue, 19 Nov 2024 17:32:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vianet.ca; h=subject:to:references:from:message-id:date:mime-version:in-reply-to:content-type:content-transfer-encoding; s=role; t=1732037550; bh=dH0+oAJLm4/IlLRN8u2+DgRmj5RhmdfiLtniuwvDtpM=; b=PELvspEMLX48ZpAGXetaj5NgZcsjqw4tVQTQehNbNvG2OI/JFsXAzNwT28U3CkY7tMSl2c8xa8CDDsq6ssd1UltE0sqkXbSYmR6/H7/AxHXNcazONoJBvA7Q2NLuOwmCGsIiYQrjz/Wx3hyjQieKUozM1fj5MBNgYlxGpBfjKF9jpGmj8rl2SMhf9I5BocfYK5X0Qw41B4y2GvlE3QS6/1NgtK7g7VGgDTTLESXRxSUlGIPku8uZS7FNaqzq12KxgKc1CS5dp1t2cnlyCj3gjEhQfX22gpKOWljI0vTd/cTQKFfGiMsa0ZO3lfzG+Mg1f6oNxpCCp7tYVG7eGQnyYg== Received: from [172.18.32.7] (static-209-91-130-140.vianet.ca [209.91.130.140]) (Authenticated sender: kdeugau@vianet.ca) by smtp2.vianet.ca (Postfix) with ESMTPSA id 6626523CEF for ; Tue, 19 Nov 2024 12:32:30 -0500 (EST) Subject: Re: Guidance Needed for PostgreSQL Upgrade from 12 to 15 To: pgsql-admin@lists.postgresql.org References: <0b8c1b80-93f5-40a7-b67b-19e58207c12c@cloud.gatewaynet.com> <9724B260-8B0E-4B03-A66A-784F792459C9@elevated-dev.com> From: Kris Deugau Organization: Vianet Internet Solutions Message-ID: <355729f6-74a0-1b5c-a065-bd919507a490@vianet.ca> Date: Tue, 19 Nov 2024 12:32:29 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 SeaMonkey/2.53.19 MIME-Version: 1.0 In-Reply-To: <9724B260-8B0E-4B03-A66A-784F792459C9@elevated-dev.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Scott Ribe wrote: >> On Nov 18, 2024, at 12:10 PM, Achilleas Mantzios wrote: >> >> >> I'd like to add if someone can tolerate some seconds of downtime, with logical replication it is possible to swap the roles of publisher / subscriber so that one can keep the old database as a means of extra safety. If his/her app breaks beyond repair and there is no time for fixing, one can simply go back to the old DB with some minor adjustments (such as sequences). > > In the same vein, if one's file system offers atomic snapshots: > > 1) shut down PG > 2) run pg_upgrade with the hard links option > 3) take snapshot > 4) start up new PG > > Now, if there's a failure, you can go back to the snapshot and either start up the old PG, or do some troubleshooting and try upgrading again. Er... I would think that you'd want to do: 1) shut down PG 2) take snapshot 3) run pg_upgrade with the hard links option 4) start up new PG as otherwise the old PG won't start properly, due to the changes made by pg_upgrade. -kgd