Re: Handling glibc v2.28 breaking changes

2022-04-25 Thread Pradeep Chhetri
Thank you Laurenz and Nick. That sounds like a good plan to me. Best Regards, Pradeep On Mon, Apr 25, 2022 at 9:44 PM Nick Cleaton wrote: > On Mon, 25 Apr 2022 at 12:45, Laurenz Albe > wrote: > >> >> You could consider upgrade in several steps: >> >> - pg_upgrade to v14 on the current operatin

Re: Handling glibc v2.28 breaking changes

2022-04-25 Thread Nick Cleaton
On Mon, 25 Apr 2022 at 12:45, Laurenz Albe wrote: > > 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 o

Re: Handling glibc v2.28 breaking changes

2022-04-25 Thread Laurenz Albe
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 u

Re: Handling glibc v2.28 breaking changes

2022-04-24 Thread Pradeep Chhetri
Hi Adrian, Thank you for your quick response. By zero downtime, I meant at least one of the three nodes is up at any time to handle the writes and reads. > Define how the 3 node cluster works? These 3 nodes are configured as 1 primary, 1 sync replica and 1 async replica. These are managed via st

Re: Handling glibc v2.28 breaking changes

2022-04-24 Thread Adrian Klaver
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