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 1tDV1w-0018xw-WF for pgsql-admin@arkaria.postgresql.org; Tue, 19 Nov 2024 20:41:01 +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 1tDV1u-00GsFA-V7 for pgsql-admin@arkaria.postgresql.org; Tue, 19 Nov 2024 20:40:58 +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 1tDV1u-00GsEu-DY for pgsql-admin@lists.postgresql.org; Tue, 19 Nov 2024 20:40:58 +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 1tDV1q-002oAY-Ls for pgsql-admin@lists.postgresql.org; Tue, 19 Nov 2024 20:40:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vianet.ca; h=subject:to:cc:references:from:message-id:date:mime-version:in-reply-to:content-type:content-transfer-encoding; s=role; t=1732048851; bh=VZANWmtiZ/oxlV8mK/JOhdinCOB85HLKWYpiEi2BFKs=; b=uHKWOMZmq+cVBfFeH5QuBlKmtEaNvADA/wlFPsmfPaGVTUBvvNZLVmspnlvopS7eJIKXZkDLe9dKcbn9JVi0Ckb5BgBK/9XW2UTdEUG81wXi7U5SGp53ZDf2s/u8WFGeeQfDWTxJETqUBxj9rQi9keVhOv5UD+3GmTI47WPqN5WMEwfmhQNGpV49AZp0HCPajFoytu+wPWNP0XAopo5gKGQ1UzZrMMCTrUL2gzu8jBk5oxBxIyWeXW8FmM8bR7QgWTS+GuiTMPNeyZ4Ed1SJCQJlUizUdK+scJDkM+btv3pzjAcZQT9z00ICEwwK420QoPLt8DTVQfOyQKuVMqKi4w== 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 93AC223D0D; Tue, 19 Nov 2024 15:40:51 -0500 (EST) Subject: Re: Guidance Needed for PostgreSQL Upgrade from 12 to 15 To: Scott Ribe Cc: pgsql-admin@lists.postgresql.org References: <0b8c1b80-93f5-40a7-b67b-19e58207c12c@cloud.gatewaynet.com> <9724B260-8B0E-4B03-A66A-784F792459C9@elevated-dev.com> <355729f6-74a0-1b5c-a065-bd919507a490@vianet.ca> <39901423-2003-493F-8A5C-12D1B1062F00@elevated-dev.com> From: Kris Deugau Organization: Vianet Internet Solutions Message-ID: <46c1255a-725f-3f0d-a18f-e1a9c20dd36e@vianet.ca> Date: Tue, 19 Nov 2024 15:40:51 -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: <39901423-2003-493F-8A5C-12D1B1062F00@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 19, 2024, at 10:32 AM, Kris Deugau wrote: >> >> as otherwise the old PG won't start properly, due to the changes made by pg_upgrade. > > Not true, pg_upgrade leaves it in a state where either can be started. By taking the snapshot after, if you roll back to it, you can attempt changes on either the old or new. (Taking care to take additional snapshots as needed, to preserve the ability to roll back to this state.) I stand corrected. I hadn't read the docs on pg_upgrade for quite a while, but after reading the last section in https://www.postgresql.org/docs/current/pgupgrade.html: "If you did not start the new cluster, the old cluster was unmodified except that, when linking started, a .old suffix was appended to $PGDATA/global/pg_control. To reuse the old cluster, remove the .old suffix from $PGDATA/global/pg_control; you can then restart the old cluster." I see what you mean. -kgd