Re: Handling glibc v2.28 breaking changes

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 <nick(at)cleaton(dot)net> wrote:

> 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.
>
>