| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| 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-25 11:45:24 |
| Message-ID: | cdcde4eb6a22423c4ea5b36be287e979ec355d89.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Sun, 2022-04-24 at 23:31 +0800, Pradeep Chhetri wrote:
> 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.
Don't use an old glibc.
You will want to move to a different machine or upgrade the operating system, so you will
have some down time anyway.
You could consider upgrade in several steps:
- pg_upgrade to v14 on the current operating system
- use replication, than switchover to move to a current operating system on a different
machine
- REINDEX CONCURRENTLY all indexes on string expressions
You could get data corruption and bad query results between the second and the third steps,
so keep that interval short.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nick Cleaton | 2022-04-25 13:44:32 | Re: Handling glibc v2.28 breaking changes |
| Previous Message | Pradeep Chhetri | 2022-04-24 16:13:57 | Re: Handling glibc v2.28 breaking changes |