Re: OS upgrade on postgres servers

On Tue, Mar 17, 2026 at 6:45 AM vrms <vrms(at)netcologne(dot)de> 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 <rajeshkumar(dot)dba09(at)gmail(dot)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(at)gmail(dot)com> wrote:
>>
>>> On Mon, Mar 16, 2026 at 2:57 PM Raj <rajeshkumar(dot)dba09(at)gmail(dot)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!
>
>
>
>

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