Re: Handling glibc v2.28 breaking changes

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Pradeep Chhetri <pradeepchhetri4444(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Handling glibc v2.28 breaking changes
Date: 2022-04-24 15:43:45
Message-ID: fa544cc1-23d8-4841-77ed-e8c38ffa35bb@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 4/24/22 08:31, Pradeep Chhetri wrote:
> Hello everyone,
>
> I am sure this has been discussed multiple times in the past but I would
> like to initiate this discussion again. I have 3 nodes cluster of
> Postgres v9.6. They all are currently running on Debian 9 (with glibc
> v2.24) and need to upgrade them to Debian 10 (with glibc v2.28) without
> downtime. In order to bypass the glibc issue, I am trying to evaluate
> whether I can compile glibc v2.24 on Debian 10, pin postgres to use this
> manually compiled glibc and upgrade the linux distribution in rolling
> fashion. I would like to know how others have achieved such distro
> upgrades without downtime. I am new to Postgres so please pardon my
> ignorance.

You are going to have to be more specific as upgrading a distro involves
downtime. I'm guessing you mean downtime for Postgres, still at least
one of the instances is going to be down while it's OS is being
upgraded. So:

1) Define how the 3 node cluster works?

2) What is the locale for the Postgres instances?

3) What is acceptable downtime in the process?

4) Are you using ICU collation?

Also you might want to look at:

https://wiki.postgresql.org/wiki/Locale_data_changes

>
> Thank you for your help.
> Best regards,
> Pradeep

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Pradeep Chhetri 2022-04-24 16:13:57 Re: Handling glibc v2.28 breaking changes
Previous Message Pradeep Chhetri 2022-04-24 15:31:21 Handling glibc v2.28 breaking changes