public inbox for [email protected]
help / color / mirror / Atom feedOS upgrade on postgres servers
6+ messages / 3 participants
[nested] [flat]
* OS upgrade on postgres servers
@ 2026-03-16 18:57 Raj <[email protected]>
2026-03-16 19:11 ` Re: OS upgrade on postgres servers Ron Johnson <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Raj @ 2026-03-16 18:57 UTC (permalink / raw)
To: Pgsql-admin <[email protected]>
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? What's the best procedure
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: OS upgrade on postgres servers
2026-03-16 18:57 OS upgrade on postgres servers Raj <[email protected]>
@ 2026-03-16 19:11 ` Ron Johnson <[email protected]>
2026-03-16 19:44 ` Re: OS upgrade on postgres servers Raj <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Ron Johnson @ 2026-03-16 19:11 UTC (permalink / raw)
To: Pgsql-admin <[email protected]>
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!
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: OS upgrade on postgres servers
2026-03-16 18:57 OS upgrade on postgres servers Raj <[email protected]>
2026-03-16 19:11 ` Re: OS upgrade on postgres servers Ron Johnson <[email protected]>
@ 2026-03-16 19:44 ` Raj <[email protected]>
2026-03-16 20:00 ` Re: OS upgrade on postgres servers Ron Johnson <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Raj @ 2026-03-16 19:44 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; +Cc: Pgsql-admin <[email protected]>
Pgdg repo
100Gb
Outage window - our decision. Client will accept our plan.
Postgres upgrade may or may not be needed. Need help on both the scenarios
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!
>
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: OS upgrade on postgres servers
2026-03-16 18:57 OS upgrade on postgres servers Raj <[email protected]>
2026-03-16 19:11 ` Re: OS upgrade on postgres servers Ron Johnson <[email protected]>
2026-03-16 19:44 ` Re: OS upgrade on postgres servers Raj <[email protected]>
@ 2026-03-16 20:00 ` Ron Johnson <[email protected]>
2026-03-17 10:45 ` Re: OS upgrade on postgres servers vrms <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Ron Johnson @ 2026-03-16 20:00 UTC (permalink / raw)
To: Pgsql-admin <[email protected]>
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!
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: OS upgrade on postgres servers
2026-03-16 18:57 OS upgrade on postgres servers Raj <[email protected]>
2026-03-16 19:11 ` Re: OS upgrade on postgres servers Ron Johnson <[email protected]>
2026-03-16 19:44 ` Re: OS upgrade on postgres servers Raj <[email protected]>
2026-03-16 20:00 ` Re: OS upgrade on postgres servers Ron Johnson <[email protected]>
@ 2026-03-17 10:45 ` vrms <[email protected]>
2026-03-17 14:42 ` Re: OS upgrade on postgres servers Ron Johnson <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: vrms @ 2026-03-17 10:45 UTC (permalink / raw)
To: [email protected]
@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 <[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!
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: OS upgrade on postgres servers
2026-03-16 18:57 OS upgrade on postgres servers Raj <[email protected]>
2026-03-16 19:11 ` Re: OS upgrade on postgres servers Ron Johnson <[email protected]>
2026-03-16 19:44 ` Re: OS upgrade on postgres servers Raj <[email protected]>
2026-03-16 20:00 ` Re: OS upgrade on postgres servers Ron Johnson <[email protected]>
2026-03-17 10:45 ` Re: OS upgrade on postgres servers vrms <[email protected]>
@ 2026-03-17 14:42 ` Ron Johnson <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Ron Johnson @ 2026-03-17 14:42 UTC (permalink / raw)
To: Pgsql-admin <[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!
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-03-17 14:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-03-16 18:57 OS upgrade on postgres servers Raj <[email protected]>
2026-03-16 19:11 ` Ron Johnson <[email protected]>
2026-03-16 19:44 ` Raj <[email protected]>
2026-03-16 20:00 ` Ron Johnson <[email protected]>
2026-03-17 10:45 ` vrms <[email protected]>
2026-03-17 14:42 ` Ron Johnson <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox