Re: Handling glibc v2.28 breaking changes

Поиск
Список
Период
Сортировка
От Pradeep Chhetri
Тема Re: Handling glibc v2.28 breaking changes
Дата
Msg-id CAJSq+arqoCG2V42Y4dNY2yv_RHDYbp3G=wSzfcwpbQowjS_Thg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Handling glibc v2.28 breaking changes  (Nick Cleaton <nick@cleaton.net>)
Список pgsql-general
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@cleaton.net> wrote:
On Mon, 25 Apr 2022 at 12:45, Laurenz Albe <laurenz.albe@cybertec.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.

В списке pgsql-general по дате отправления:

Предыдущее
От: Nick Cleaton
Дата:
Сообщение: Re: Handling glibc v2.28 breaking changes
Следующее
От: Robert Treat
Дата:
Сообщение: Re: LwLocks contention