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 1tIoj1-00Gp7G-Ie for pgsql-general@arkaria.postgresql.org; Wed, 04 Dec 2024 12:43:27 +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 1tIohz-00GyGQ-Gz for pgsql-general@arkaria.postgresql.org; Wed, 04 Dec 2024 12:42:24 +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 1tIohz-00GyGI-4d for pgsql-general@lists.postgresql.org; Wed, 04 Dec 2024 12:42:24 +0000 Received: from sonic302-21.consmr.mail.ne1.yahoo.com ([66.163.186.147]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tIohx-0010h4-Dg for pgsql-general@postgresql.org; Wed, 04 Dec 2024 12:42:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1733316139; bh=7mSI212KzU8jwh2bNpiI+d7rQ9ruYDjqtnlxhe+RoLI=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=IBczFtcMdsE28DcBSsKoRmfvHFlaNL9tisxOrv58VkXotmCeY0f5jpuX6++EEyXpqCeYm+UpCWginJnBWJCUrEWFUshkSaH99xnmatAp8Orw+6uSMQUScMQ9e1Yb5J8M1r+DG+jNnv0SKQHOtGfNbeUjiMGtpp5zb7hL1gTO3ftdGC3koDAw9aU6STRRFKjUxzEbPMASjX/IQ2LNcClakJEmNl3vIGErsm2cuSyltOljcyc4gpPPKKGtDLR0o/Bcpw9w1zyoUTfB4x5bZk9afJ2As/gPqKT8ZbOdrGgaFoZbWn2nPmxnwAjcllONSjo00UhSoeLo3Jkxezdv4rmbEA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1733316139; bh=29qCNsAHDdjeG0CnyATeAY6IazhgDCr+J0rfEtwYP8u=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=h5YzBODz0LJSAAbxm8l1oMwS9YAuMMVJygbeEx5hsuRm5OtQzm5uJVf5zvFpSHDHvz0ddcswT7SMVXqdxLBWvyTZsxuy42XHn4nUryDw/kewJX966cN9Q0yVWj7A2ZqJdHqEL6PLHv9qKMuwOnd9jns3+1nzDvXBJFUlc5OIMX4HIi8rsjCyfRedapW6tFL54PprFTM+nbQ3hKiDPqTCi71xvNqXAsX2En/Qmq8H9vERYB+OARKp/4JoNU89eU32XjhiSFAW8yZvspv+Kp2eL8vjD/vjTlKibCHhH6zYwI+feP6ILUG2ShOItbAFYTz7OJTo8+a4dB2Ej7tRaMnsUQ== X-YMail-OSG: nAyoHw0VM1k1IIIJgEAHeERS1QFmNHKJjk3erDhwARRFm.lj9NmI00ugdlNfKXJ JlMdbmHJkqiuldx7K59bEHDFp7ohsEpdgO344x0pwrhY8hI1lCToOvPk9ka_T5VMhRmN71JNQHKU bmv4GflZy__00tuC47iMdwkxoaQS_3EPqluHxO_4NxliN.od8vgnSss_67g406G_j6Vz8LC5tNwv QJ5nx9R.TeArdSNTieYdhd_y3aOGu2XaduLvA6tsGVWBZ7V3VhTs6YlX3Hdt.uFnSNAOkCwJr4a4 Ynnt2bW1wnPyVh9IBbvh3HTlrMGEnDqKOeXzcPnUkuAgOyVKiFD4A9qWFW8250TqRoVdnWTBMoWt 6DWPdJx_PyZwcdWDl6oQgCtnlbjp3HvbNlo26dLRavBshcy15QmtfCcA6JQqHMZu0ENl3_p9YqTW tFrUWcaKoG2GlftVUj8fD0r6u6.KfLZk4eaRKnEqMJy39Fi9vnSL1.wtiW34dgXQd07vRTcqLR3D FyGsNEVG0mdHg7pjV6HDir2b0uzTHYReLIZl8h.hwrCCq4C3N8N8exUXSHDSpkV6ttXku2QA561f zTqQhYQVczLemwjGoFCUf9s95VW05WRgez84OVck1ECouBr0PhYfxNJWI6U1RPqwLjnbkvuCfu6Y ut1mQNH4yIBVHQ_piKZ_rDFcRPVBY1rQQqM69r3BN7FGA5x3.N2Q5O4SygPudcG.N5wRwVTRZAAc lcseJDtQjKjg74xrkXl8lJL9ySv9qZd5vUDdsSAXkjZey.RjxMIcAagKTnNdJ5mZaCnnCnKapxXD kYcuc7WIfXgdfiOFTO8xwuZbt9srxdmabTT0Y_gwSZ.Bwp.ow2CEIe0yMRSyqXSHCxhLyuaFSf.7 ZM8_TlL34RaFDCEf_CO0SPFMOKW3SyeSxbeWdhfrUJbjPArBOtfJfntNSLVG0ePy9tQT1X9mld03 exoPYB1lvWtLdIvd.zwXPWQuAepGOGxm30COAxcg2kTPIwGQxtrQANYg5DaOcPsRwVvPaRvLVkvk RqmsASpb4CMPUu1Y5jPGKar5nMJXQOXm3gSKRmiOWbt6ZwkHM8kJI4ZTW2lH5tDPFHeXJ6ZxC7zc oyuiubiLDQUE_rAtLGjOvFvsoyA8zCxAYVgPFTymA1G39Mayl07rRxEXYMMyzZ_lgNSC0_APIUZf 1Bk54Qd6anr2Ar6gDxDXRme0B2ro_frYtBR9catNBXX7ILDvBxjMVNKafF8rL7P7LuxExY8AB_Pa TNW819uPNxi4drEjsDUo14CJM61qM_8E1CfWDRTlyEucEXWOqy8.OuWUxSNJLHK1qW9w3qVn1yl4 HWSmlkP.DH.u5Qg2fZX2_djPOZon97I8r.EizmZRLEGUQNTXNpD3UWCoRqbZi1HGnC88v6roNrXZ rUZa.R1pdYMYmZBRDXZmhOCIr1RdGOyBzMvEWzSIi0tghcTv1jYelDx2LApFV.RhnWFNe3p.59Vv Qwx1XLP3DseZfPTD_4t7pi_gho85.uHqsz8GZbYN8eHEGhpKJNpdq0NgaGsiQLzDkhsfpVmls2j_ t2Q0KSaY_Yt7MLsn2l7zQh_HguSPtU0whU8m9WHv2g1lALQVGUQ7xAyE5RAt_CPdPwa1UkJ2A_8t vunIx37pL4pPzasxMQ3vUkJicTTraM1Mf71L4l7oJ2rhcrsPqExshP7Ckz7s1lWyz8ZYy9hLVWoF XwwZQ65E4EOfXn0MnNIYTLHbFQJ77uBDW_PeHXwKdezJbNd2j4v2aVu_fNZ5cVrXPz0WUr.rwxkB KI7NexqR1kngxz0487lVV3hQXkRJh9H5e3V5.3nmMWwdyWxoqKxP289yI3iSGOaYsv48Ms56D7cm i5Da1TPDBB107fKQ5zwE8nf4glNQQ8jhhapApDV9HU2QMcQy_X8hXQCcFNaE72Os0HnfF4UHqlEn 6hgpkDluVotLIa0dwlQu7SPYN6zXpMzr3b5DLfv95zs9rx1NYGioNDnxEWyzk..iwvny9dZOWqMU nZ6ycYe5k4AzLJPJ7E5rB5wBP8X5KJalYlY6nccCOxMwRkWZARsBDdxhVmG9OC1OtzSGkbYUSVOe J.t3ICKCo4OBXZt3h4nyRXKOIdDZ0KIgTejHWzlPyzl7J8FOD2UJsHoIJKWIV1EmrNFzstHka3RO J6zhjMkxlauDADX7Q64.NF19gP2FlSqaX2SGJy3hAAwRydhksP1bXqAFgSW655rNiRUMvFkkbD9Y a8DjFr2MvxUY4Dd8KL5B8X.LjSrOmQtKpASJwGCicWBEIF1Sj5ZJ6LV3DJ_8eb6U0fqZWPEIN X-Sonic-MF: X-Sonic-ID: 52c2680f-b384-4ccd-9b15-5235edabcbd7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Wed, 4 Dec 2024 12:42:19 +0000 Date: Wed, 4 Dec 2024 12:42:17 +0000 (UTC) From: Bharani SV-forum To: Ron Johnson , pgsql-general , Adrian Klaver Message-ID: <1061066336.5835157.1733316137292@mail.yahoo.com> In-Reply-To: <498dfb34-4dd7-4f48-8188-355e1488d7e6@aklaver.com> References: <0558ddd4d71641bdb41fa49b2425f73c@safrangroup.com> <98965993.3138805.1731699978332@mail.yahoo.com> <564950518.5117550.1733177884387@mail.yahoo.com> <07ab2d83-ffe5-4bec-9626-22a68f732579@aklaver.com> <273a88dc-4134-47d5-bc19-30ff5f97926c@aklaver.com> <498dfb34-4dd7-4f48-8188-355e1488d7e6@aklaver.com> Subject: Re: Help in vetting my steps for Postgres DB upgrade from Ver 13.X to ver 15.X MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5835156_10212233.1733316137290" X-Mailer: WebService/1.1.22941 YMailNorrin Content-Length: 12509 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_5835156_10212233.1733316137290 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Team /Ron/Adrian Wann to reconfirmwe have an setup with=C2=A0 new server will be with=C2=A0 will be following the following suggestion On old VM [=C2=A0existing server with OS=C2=A0"Amazon Linux release 2 (Karo= o) " present in aws "us-east-1 region" and along with postgresql ver 13.16.= 2=C2=A0 - community edn ] =C2=A0- "take offline full backup (PG_DATA folder alone)=C2=A0 using OS com= mand" On new VM [OS "Amazon Linux 2023 " in aws region=3Dus-east-1 and intended d= b as "postgresql 15.10 - community edn" ]=C2=A0 =C2=A0- "Restore offline full backup (PG_DATA folder alone) using OS comman= d" - create postgres unix userid- install postgresql ver 15.10 binaries- setup= respective env variable to point correctly for PG_DATA - will follow "pg_upgrade" my question is=C2=A0a) is the above said steps is correct with the given ex= isting and proposed setupb) is their any known issues using "cross over usi= ng pg_upgrade " option between the server's having below said operating sys= tem=C2=A0- source =3D existing server with OS =3D=C2=A0Amazon Linux release= 2 (Karoo) " present in aws "us-east-1 region" and along with postgresql ve= r 13.16.2=C2=A0 - community edn=C2=A0 vstarget - different server=C2=A0OS "Amazon Linux 2023 " in aws region=3Dus= -east-1 and intended db as "postgresql 15.10 - community edn" On Tuesday, December 3, 2024 at 12:28:58 AM EST, Adrian Klaver wrote: =20 =20 On 12/2/24 17:23, Ron Johnson wrote: > Adrian, >=20 > OP is moving to a new VM when=C2=A0migrating to PG 15.=C2=A0 When was the= =20 > "cross-server" feature added to pg_upgrade? >=20 Moving to a new VM was not the issue, my mistake was thinking the OS=20 version was staying the same. Then: On old VM: "take offline full backup (PG_DATA folder alone)=C2=A0 using OS command" On new VM: "Restore offline full backup (PG_DATA folder alone) using OS command" Followed by installing new Postgres version could be dealt with using=20 pg_upgrade. Once I was corrected on what was actually going on then=20 doing a dump/restore or logical replication became better choices. --=20 Adrian Klaver adrian.klaver@aklaver.com =20 ------=_Part_5835156_10212233.1733316137290 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Team /Ron/Adrian

Wann to reconfirm
we have an setup with 

<= div dir=3D"ltr" data-setdir=3D"false">new server will be with&nbs= p;

=
will be following th= e following suggestion
<= span style=3D"color: rgb(29, 28, 29); font-family: Slack-Lato, Slack-Fracti= ons, appleLogo, sans-serif; font-size: 15px; background-color: rgb(248, 248= , 248);">
On old VM [&n= bsp;existing server with OS "Amazon L= inux release 2 (Karoo) " present in aws "us-east-1 region" and along with p= ostgresql ver 13.16.2  - community edn ]

 - "take offline full backup (PG_DATA folder alone) = ; using OS command"

On new VM [OS "Amazon Linux 2023 " in aws region=3Dus-east-1 and intended db as "p= ostgresql 15.10 - community edn" ] 

 - "Restore o= ffline full backup (PG_DATA folder alone) using OS command"
- create postgres unix userid
- install postgresql ver 15.10 binaries
- setup respective env variable to poin= t correctly for PG_DATA
- will follow "= pg_upgrade"


my questi= on is 
a) is the above said steps is correct with the given existing = and proposed setup
b) is their any known issues using "cross over using pg_= upgrade " option between the server's having below said operating system&nb= sp;
- source =3D existing server with OS =3D Am= azon Linux release 2 (Karoo) " present in aws "us-east-1 region" and along = with postgresql ver 13.16.2  - community edn 
<= span>vs
target - different server&n= bsp;OS "Amazon Linux = 2023 " in aws region=3Dus-east-1 and intended db as "postgresql 15.10 - com= munity edn"

<= br>
=20
=20
On Tuesday, December 3, 2024 at 12:28:58 AM EST, Ad= rian Klaver <adrian.klaver@aklaver.com> wrote:


=20 =20
On 12/2/24 17:23, Ron Johnson wrote:<= br clear=3D"none">> Adrian,
>
&g= t; OP is moving to a new VM when migrating to PG 15.  When was th= e
> "cross-server" feature added to pg_upgrade?
>

Moving to a new VM = was not the issue, my mistake was thinking the OS
versio= n was staying the same.

Then:

On old VM:

"take offline full backup (PG_DATA folder alone)  using OS command"<= br clear=3D"none">
On new VM:
"Restore = offline full backup (PG_DATA folder alone) using OS command"

Followed by installing new Postgres version could be= dealt with using
pg_upgrade. Once I was corrected on wh= at was actually going on then
doing a dump/restore or lo= gical replication became better choices.
------=_Part_5835156_10212233.1733316137290--