| From: | Nick Cleaton <nick(at)cleaton(dot)net> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| Cc: | Pradeep Chhetri <pradeepchhetri4444(at)gmail(dot)com>, PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Handling glibc v2.28 breaking changes |
| Date: | 2022-04-25 13:44:32 |
| Message-ID: | CAFgz3kutPEYtiN-j1e2v6YcC3o25-PohqombFdJe3N0mXAenZg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, 25 Apr 2022 at 12:45, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> 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 on string expressions
>
> You could get data corruption and bad query results between the second and
> the third steps,
> so keep that interval short.
>
We did something like this, with the addition of a step where we used a
new-OS replica to run amcheck's bt_index_check() over all of the btree
indexes to find those actually corrupted by the libc upgrade in practice
with our data. It was a small fraction of them, and we were able to fit an
offline reindex of those btrees and all texty non-btree indexes into an
acceptable downtime window, with REINDEX CONCURRENTLY of everything else as
a lower priority after the upgrade.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pradeep Chhetri | 2022-04-25 14:31:34 | Re: Handling glibc v2.28 breaking changes |
| Previous Message | Laurenz Albe | 2022-04-25 11:45:24 | Re: Handling glibc v2.28 breaking changes |