Search Postgresql Archives

Re: Handling glibc v2.28 breaking changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 25 Apr 2022 at 12:45, Laurenz Albe <laurenz.albe@xxxxxxxxxxx> 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.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux