Re: Handling glibc v2.28 breaking changes

Поиск
Список
Период
Сортировка
От Nick Cleaton
Тема Re: Handling glibc v2.28 breaking changes
Дата
Msg-id CAFgz3kutPEYtiN-j1e2v6YcC3o25-PohqombFdJe3N0mXAenZg@mail.gmail.com
обсуждение исходный текст
Ответ на Handling glibc v2.28 breaking changes  (Pradeep Chhetri <pradeepchhetri4444@gmail.com>)
Ответы Re: Handling glibc v2.28 breaking changes  (Pradeep Chhetri <pradeepchhetri4444@gmail.com>)
Список pgsql-general
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 по дате отправления:

Предыдущее
От: Laurenz Albe
Дата:
Сообщение: Re: Handling glibc v2.28 breaking changes
Следующее
От: Pradeep Chhetri
Дата:
Сообщение: Re: Handling glibc v2.28 breaking changes