public inbox for [email protected]  
help / color / mirror / Atom feed
From: Ron Johnson <[email protected]>
To: Pgsql-admin <[email protected]>
Subject: Re: OS upgrade on postgres servers
Date: Tue, 17 Mar 2026 10:42:59 -0400
Message-ID: <CANzqJaDYLrhH32rUnrETb0G54C915SOGwdj3FCbM=51pLOsKAA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAJk5AtbW=741yyD5+oV9yHSU40E4g57SY5DLRcJXsEK5-YFRig@mail.gmail.com>
	<CANzqJaDdOPGTE3wjgVA4rsPsG2j44JjvDZLKw0DFnnwauEFw8g@mail.gmail.com>
	<CAJk5AtaJkt1wETETV88LvY9NQwAC6KF35Q=L-rekGk=zLEfWcg@mail.gmail.com>
	<CANzqJaBeJzmsF+OE8v8BR6v72WChr5F+4WUjRuzZ1dxb9UzwgA@mail.gmail.com>
	<[email protected]>

On Tue, Mar 17, 2026 at 6:45 AM vrms <[email protected]> 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 <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.
>

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 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 <[email protected]> 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, <[email protected]> wrote:
>>
>>> On Mon, Mar 16, 2026 at 2:57 PM Raj <[email protected]> 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!
>
>
>
>

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


reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: OS upgrade on postgres servers
  In-Reply-To: <CANzqJaDYLrhH32rUnrETb0G54C915SOGwdj3FCbM=51pLOsKAA@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox