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.96) (envelope-from ) id 1w2Vdb-000M17-2G for pgsql-admin@arkaria.postgresql.org; Tue, 17 Mar 2026 14:43:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w2Vda-002Fll-26 for pgsql-admin@arkaria.postgresql.org; Tue, 17 Mar 2026 14:43:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w2Vda-002Flc-09 for pgsql-admin@lists.postgresql.org; Tue, 17 Mar 2026 14:43:14 +0000 Received: from mail-oi1-x22a.google.com ([2607:f8b0:4864:20::22a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w2VdW-00000000CPW-2JGZ for pgsql-admin@lists.postgresql.org; Tue, 17 Mar 2026 14:43:13 +0000 Received: by mail-oi1-x22a.google.com with SMTP id 5614622812f47-466ec4c6852so3661984b6e.3 for ; Tue, 17 Mar 2026 07:43:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773758591; cv=none; d=google.com; s=arc-20240605; b=RHjuhKqFmcCcv1E9UL1BL49dT2KKq44LAg4IEWwD7MptMOaGkIbPULyQhTxhXUp6q0 yRLOyW88nCbcfso6Vxb3tcbjRrAqxvhXHcdR5RAd9uDrtrePrLSF0oTADlr0MFMezqRE 29pEDPd9PKdIhTx3ZW4B0ISmWKuDxWsfuH1CF2woHC/jeYAZnvxsD8Qiyz+hJ3Pqe63v ZkA6zD4S6M94TNmeWYxwk31sUzwSGIwzMYD0pnMWdjOIa8M63FRdz0www2Hkwo7fpp7w CC2E2wnz8EH7vn8pqsL87dyUSH0PeDcFjMGYLIuRCh85P+lUl7ZNQhBP0ZDSJ8v56O82 uKPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=ddSSvBuf4lPytIqZ2SIH8ay14xhct1H7FNcaPtBxKRs=; fh=druxZHa2fk4e6MLibibygn9AWWgeaAPo4m8Gpo2MBXU=; b=CreZrZpRqlzqTtM7Mrh280vroanLJQEaClRa/cZ+iyqCUC98pY7eqihFDNbVDWKPeK k+ae1LxMY4pEBvTl9VGJ0qozXUUb7K9ba1fVPUTxyMhcQzZShydlU4EZPUDKh/fUit9W 0MBLMWtYU5HiHzjG6exw/qQ84XCvZrs9LFYIVFOICywPZLUVi/UFcJpnmnWBlUt6pjiN hkuK0I8vvhfoz6gTuyga2PPMa1nBp3K2C6d9ZnbNVlnENpaqokCYErm2aVkWHdBOtG2Q vJd6Cieu/fJGdtKNRyhUTZ+0nyye2Rot9vEfhnUneRULHVtGc6fRA1C3sqaUuM4nigAW u84g==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773758591; x=1774363391; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=ddSSvBuf4lPytIqZ2SIH8ay14xhct1H7FNcaPtBxKRs=; b=HHLre8QBZeRA6XRmNM24OJFQDDknc6lB6GzaO+NHSXMZEl/pwDJ896gU5zeCBtYNs0 N0nYxfdN7qaqgjIMhPXVhX4Pl39Tk6YC7FbYk6Z/C9oLA9lBNrIHxWamKqE1o2wKAMOH I4Q6SX7mp4U5Ce93HSUO00hQIS/ZlYX4qfyxA4Wvru4U665Vka2ykk9VaxdIFLQn9QUa jIqrAMTB7LBpqIA3RLcSjI28I+D1SlOGpj0+Qy8WD0NrSTBsOyoJpyooL8AS4icn+oJs jQs/kvfbgv8a+Hy7Dxbg5DSGDROhQr1kNcbZzcyHas59YDaM6hnvw4BqfEPtP9akPQIl E9+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773758591; x=1774363391; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ddSSvBuf4lPytIqZ2SIH8ay14xhct1H7FNcaPtBxKRs=; b=ibZlNp4huPvD7nOqzxfp1uVtwDFKrmNRhEDY5XHxJacGv1GcmDIGxniH8ePYmnNZXN wdq/cdgXk9Wjf0BWxd/JufMhieWMIrdr3stZ2Ev8GR0eOeLAPCSkrlY+weL3d5+sOqV0 2nZn651FuaHt/5IiG9Od/2KVeVYsqUW7JY0xHdpshC2Ak2ibb8EoMddy1jumu2VrWFpP VL9OxjMMuzkHfJFpTt7Zz/9L+FAQE2Ghehi7mqa4YKx92kWY0GGlTCr0R04ZpRC9OFjh iKt9mo0orEwEvWXRv01+XVPLOYKrUJcxoqex9Z1ujtD/TDlbjT4Poq/+OWKVhsBemjkC 72aA== X-Gm-Message-State: AOJu0Ywpf3nMNlCR0uqDe7nKl+PkpeS/aPByMRIerxpsFTN1v2y3DxuI X0PApCC0pNhU/ynZoC5wesP4192nhsBM3FgBaQrggfMdo67v7nOz8mEMvu5ELUcz6r+xRzS37bU +UDW74ReZXdIkZQtRSOWxd7QtLujqGZIATA== X-Gm-Gg: ATEYQzyvAdKdpM+dXM4qYVx+QTzPi0KZltgZHga1ud/cpMO994G/0lq8cUSzWDcxuYk TtssWkFasKAvimChJw9cojOBEv373MEgRYeuvZqkhW3O1UipUdKbdl1y9GLlGSYFKD9XT2k75iT xurvuGd1+Ny/4z+mywJSxP+wry3sseGLDVdeIVWHH3iXOj+NaLcb6+eWj9KbH40SDQkhkSgBvDy kY1/R5JmGjsSK6RsA5wvZ3IoSxLtB3lY/wKXiU0muQVFA587aFxClZbIIcdjhs0ViK+8OfQgL50 WEGNRMc4 X-Received: by 2002:a05:6808:1b13:b0:45a:6cf0:68c1 with SMTP id 5614622812f47-46757637516mr9641661b6e.58.1773758591278; Tue, 17 Mar 2026 07:43:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Tue, 17 Mar 2026 10:42:59 -0400 X-Gm-Features: AaiRm50syWigjlZIYl63u3aFlhevhgD2h47tewWF7juI-y_Hng69woJagAq9x68 Message-ID: Subject: Re: OS upgrade on postgres servers To: Pgsql-admin Content-Type: multipart/alternative; boundary="000000000000c050e7064d395a75" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c050e7064d395a75 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 17, 2026 at 6:45=E2=80=AFAM vrms wrote: > @Ron: with 'parallel' you mean the -jX part of the pg_dump/pg_restore > commands you're suggesting, which would utilize multiple processes on the > server, right? > Correct. > > @rajeshkumar: It would also technically be possible to run a plain text > dump and pipe it through to psql on the fly. Something like > > /usr/pgsql-17/bin/pg_dumpall -v -h | /usr/pgsql-17/bin= /psql > -h localhost |& tee /path/to/transfer.out > > That way you have only one single action going on (on the target server). > You loose the option to interfere between dump and restore though. > But is: 1) single-threaded, and 2) means you can't do in-place upgrades. > > You check the out file (/path/to/transfer.out) produced by this for any > errors (grep -iE 'warning|error|fatal|notice' /path/to/transfer.out) > afterwards. > Also you need to compare password_encryption on both ends and, if it migh= t > be different (like md5 on the source, scram-sha-256 on the target), set t= he > passwords once again manually. > Assuming you have both servers running in parallel you can test those > options and see which one suits you while the source server is still > operating. > > all best > Gunnar > > On 3/16/26 21:00, Ron Johnson wrote: > > > > On Mon, Mar 16, 2026 at 3:45=E2=80=AFPM Raj = wrote: > >> Pgdg repo >> 100Gb >> > > That's relatively small. Parallel pg_dump/pg_restore should be pretty > fast. > > >> Outage window - our decision. Client will accept our plan. >> Postgres upgrade may or may not be needed. Need help on both the >> scenarios >> > > What version of PG are you currently using? (Everything older than PG 14 > is EOL, and PG 14 will go EOL this November.) > > I strongly recommend that you add the PGDG repository to yum/dnf, and the= n > install the intended version (both before and after the upgrade to RHEL10= . > > PG 17.latest or PG 18.latest are best, but of course you need to read the > release notes and test your application against that new version. > > Then, for example: > /usr/pgsql-17/bin/pg_dump -Fd -jX .... > > /usr/pgsql-17/bin/pg_restore -Fd -jX > > >> >> On Tue, 17 Mar 2026, 00:41 Ron Johnson, wrote: >> >>> On Mon, Mar 16, 2026 at 2:57=E2=80=AFPM Raj wrote: >>> >>>> Hi all, >>>> >>>> I have traditional servers with postgres with replication setup >>>> (primary - standby). OS team want to upgrade from rhel 8.10 to 10. >>>> >>>> As a dba, what is the suggestion we need to give. How do we proceed ? >>>> Should we stop the posygres servers? Should we get new servers with rh= el 10 >>>> and migrate Data? >>>> >>> >>> That's certainly a safe method. >>> >>> >>>> What's the best procedure >>>> >>> >>> The main problem is collation change driven by the newer glibc version. >>> >>> 1. How did you install PG (from the RHEL repository, or from the PGDG >>> repository)? >>> 2. How big are your databases? >>> 3. How big is your outage window? >>> 4. Do you plan on upgrading Postgresql at the same time? >>> >> > > -- > Death to , and butter sauce. > Don't boil me, I'm still alive. > lobster! > > > > --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000c050e7064d395a75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 17, 2026 at 6:45=E2=80=AFAM v= rms <vrms@netcologne.de> wr= ote:
=20 =20 =20
@Ron:=C2=A0with 'parallel' you mean the -jX part of the pg_dump/pg_restore commands you're suggesting, which would utilize multiple processes on the server, right?

Correct.
=C2=A0

@rajeshkumar: It would also technically be possible to run a plain text dump and pipe it through to psql on the fly. Something like

=C2=A0 =C2=A0/usr/pgsql-17/bin/pg_dumpall -v -h <source-server> |=C2=A0/usr/pgsql-17/bin/psql -h localhost |& tee /path/to/transfer.out

That way you have only one single action going on (on the target server). You loose the option to interfere between dump and restore though.
=

But is:
1) single-threaded, and<= /div>
2) means you can't do in-place upgrades.
=C2=A0

You check the out file (/path/to/transfer.out) produced by this for any errors (grep -iE 'warning|error|fatal|notice' /path/to/transfer.out) afterwards.
Also you need to compare password_encryption on both ends and, if it might be different (like md5 on the source, scram-sha-256 on the target), set the passwords once again manually.
Assuming you have both servers running in parallel you can test those options and see which one suits you while the source server is still operating.

all best
Gunnar

On 3/16/26 21:00, Ron Johnson wrote:
=20


On Mon, Mar 16, 2026 at 3:45=E2=80=AFPM Raj <rajeshkumar.dba09@gmail.com> wrote:
Pgdg repo
100Gb

That's relatively small.=C2=A0 Parallel pg_dump/pg_resto= re should be pretty fast.
=C2=A0
Outage window - our decision. Client will accept our plan.
Postgres upgrade may or may not be needed. Need help on both the scenarios=C2=A0

What version of PG are you currently using?=C2=A0 (Everythin= g older than PG 14 is EOL, and PG 14 will go EOL this November.)

I strongly recommend=C2=A0that you add the PGDG repository t= o yum/dnf, and then install the intended version (both before and after the upgrade to RHEL10.

PG 17.latest or PG 18.latest are best, but of course you need to read the release notes and test your application against that new version.

Then, for example:
/usr/pgsql-17/bin/pg_dump -Fd -jX ....
<upgrade RHEL to v10>
/usr/pgsql-17/bin/pg_restore -Fd -jX
=C2=A0

On Tue, 17 Mar 2026= , 00:41 Ron Johnson, <ronljohnsonjr@gmail.com> wrote:
On Mon, Mar 16, 2026 at 2:57=E2=80= =AFPM Raj <rajeshkumar.dba09@gmail.com> wrote:
Hi all,

I have traditional servers with postgres with replication setup (primary - standby). OS team want to upgrade from rhel 8.10 to 10.

As a dba, what is the suggestion we need to give.=C2=A0 How do we proceed ? Should we stop the posygres servers? Should we get new servers with rhel 10 and migrate Data?

That's certainly a safe method.
=C2=A0
What's the best procedur= e

The main problem is collation change driven by the newer glibc version.

1. How did you install PG (from the RHEL repository, or from the PGDG repository)?
2. How big are your databases?
3. How big is your outage window?
4. Do you plan on upgrading Postgresql at the=C2=A0same time?
=C2=A0

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!




--
Death to <Redacted>, and butter sauce.Don't boil me, I'm still alive.
<Redacted> lobs= ter!
--000000000000c050e7064d395a75--