Re: OS upgrade vs Postgresql

If it's a minor upgrade of the OS and Postgres, I perform the update in the
same time for all packages, starting with standby on a pre-production
environment.

On Mon, Dec 22, 2025 at 12:27 PM Raj <rajeshkumar(dot)dba09(at)gmail(dot)com> wrote:

> Thanks Anton.
>
> @fabrice. We had compatibility checks already before upgrade...but in a
> patroni cluster, what's the best approach a dba should recommended.
>
> 1. Dont upgrade pgbackrest or postgres and exclude when performing os
> upgrade?
> 2. Start upgrading DR first and then upgrade primary?
> Etc ....
>
> On Mon, 22 Dec 2025, 16:45 Fabrice Chapuis, <fabrice636861(at)gmail(dot)com>
> wrote:
>
>> Hi,
>> IMO the best thing to do is to check the release notes for PG 17.7 and
>> pgbackrest 2.57.
>> Generally speaking, there are no compatibility issues between minor
>> versions of Postgres.
>> Regards,
>> Fabrice
>>
>> On Mon, Dec 22, 2025 at 10:45 AM Raj <rajeshkumar(dot)dba09(at)gmail(dot)com> wrote:
>>
>>> Hi team,
>>>
>>> Our set up is Site1(primary - rhel 9.6, postgres 17.6 in a patroni set
>>> up+ pgbackrest 2.6v & sync replica - - rhel 9.6, postgres 17.6 in a
>>> patroni set up+ pgbackrest 2.6v) and in site2(async standby - - rhel 9.6,
>>> postgres 17.6 in a patroni set up+ pgbackrest 2.6v)
>>>
>>> We have OS upgrade from rhel 9.6 to 9.7 for two nodes in Site1. We can
>>> see postgres and pgbackrest has automatically upgraded to 17.7 and 2.57
>>> respectively.
>>>
>>> Whereas db node in site3 is no upgraded and stays with 9.6, 17.6 and
>>> 2.56 for rhel , postgres and pgbackrest version respectively.this will be
>>> upgraded tomorrow
>>>
>>> Is this a problem( we intend to upgrade only OS and not postgres) ? Is
>>> this problem or is it best way or is it a normal behaviour that can or
>>> should be avoided?
>>> What wrong we are doing?
>>> What is the right approach?
>>> Any blogs is appreciated
>>>
>>