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 1w2Rv0-000Igu-04 for pgsql-admin@arkaria.postgresql.org; Tue, 17 Mar 2026 10:44:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w2Ruy-000Svv-2I for pgsql-admin@arkaria.postgresql.org; Tue, 17 Mar 2026 10:44:56 +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.96) (envelope-from ) id 1w2Ruy-000Svn-0y for pgsql-admin@lists.postgresql.org; Tue, 17 Mar 2026 10:44:56 +0000 Received: from cc-smtpout3.netcologne.de ([2001:4dd0:100:1062:25:2:0:3]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w2Ruv-00000000aXM-24PE for pgsql-admin@lists.postgresql.org; Tue, 17 Mar 2026 10:44:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1773744291; bh=rqatKpHUWhWrVgkkaL+BhKgvWa4NBGGvZqLnYaILuIw=; h=Message-ID:Date:From:Subject:To:References:In-Reply-To:From; b=JgTfK2hZlELGPiA4Kvg0VjALGiLC452U1riWLIayN2MQHJxEgQy5m7tsXOmJTGEk1 EhC2sriBkDxTI92vdxhKABV3YmDtlet/phCHhyN52KhN9p5IMU6tJcMpGxiQfsk7nL Yj1pALnSJtfksK94hdAhU+MmUGZlG23+h0MVU0I3u5TDaZ5FBglsd1TpbZAh4af9dQ H03ChNi5RwJHlZK99lkKxPMWiMdjIsLhkwgRfKzowBhwAGovvvO54iB97PxLLrvb7o w+kScLRd/2HCxl5lQmdMHrjTNTxe56bH11kEAgJZxKogsas5QVLV0EncUjZDkaBaEZ /CyCbC8AbpTKQ== Received: from cc-smtpin2.netcologne.de (cc-smtpin2.netcologne.de [89.1.8.202]) by cc-smtpout3.netcologne.de (Postfix) with ESMTP id 25F75122C3 for ; Tue, 17 Mar 2026 11:44:51 +0100 (CET) Received: from [IPV6:2a03:b580:aff7:d901:d2:923d:27d5:50d1] (unknown [IPv6:2a03:b580:aff7:d901:d2:923d:27d5:50d1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by cc-smtpin2.netcologne.de (Postfix) with ESMTPSA id D6BAB11D67 for ; Tue, 17 Mar 2026 11:44:50 +0100 (CET) Content-Type: multipart/alternative; boundary="------------kUHhYI9zpYuY8JGNDtkrmqJy" Message-ID: Date: Tue, 17 Mar 2026 11:45:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: vrms Subject: Re: OS upgrade on postgres servers To: pgsql-admin@lists.postgresql.org References: Content-Language: en-US In-Reply-To: X-NetCologne-Spam: L 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. --------------kUHhYI9zpYuY8JGNDtkrmqJy Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit @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? @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. 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: > > > On Mon, Mar 16, 2026 at 3:45 PM 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 > 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 .... > > /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 PM 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 rhel 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! --------------kUHhYI9zpYuY8JGNDtkrmqJy Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit @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?

@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 <source-server> | /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.
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:


On Mon, Mar 16, 2026 at 3:45 PM Raj <rajeshkumar.dba09@gmail.com> 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 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
 

On Tue, 17 Mar 2026, 00:41 Ron Johnson, <ronljohnsonjr@gmail.com> wrote:
On Mon, Mar 16, 2026 at 2:57 PM 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.  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.
 
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 <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!


--------------kUHhYI9zpYuY8JGNDtkrmqJy--