Re: Q: fixing collation version mismatches

Поиск
Список
Период
Сортировка
От Karsten Hilbert
Тема Re: Q: fixing collation version mismatches
Дата
Msg-id Y3FojZ4gPMoJuMfx@hermes.hilbert.loc
обсуждение исходный текст
Ответ на Re: Q: fixing collation version mismatches  (Christophe Pettus <xof@thebuild.com>)
Ответы Re: Q: fixing collation version mismatches  (Julien Rouhaud <rjuju123@gmail.com>)
Re: Q: fixing collation version mismatches  ("Daniel Verite" <daniel@manitou-mail.org>)
Список pgsql-general
Am Sun, Nov 13, 2022 at 12:46:53PM -0800 schrieb Christophe Pettus:

> > On Nov 13, 2022, at 12:45, Karsten Hilbert <Karsten.Hilbert@gmx.net> wrote:
> >     REINDEX DATABASE db_in_question;
> >     ALTER DATABASE db_in_question REFRESH COLLATION VERSION;
> >     ALTER COLLATION every_collation_from_pg_collation REFRESH VERSION;
>
> I may be totally off-base here, but shouldn't the REINDEX be the last step?

To my understanding, the REFRESH statements "merely" update
the version information stored in the related objects. They
do not change anything else; and the REINDEX does not
reference them in any way.

I suppose the REINDEX goes first as it does the actual fixing
of now-invalid objects by rebuilding them. After that one is
back to a usable database state, even if left with pesky
(albeit harmless) warnings on version mismatches -- which to
get rid of one runs the REFRESH statements.

Or so my understanding...

Which is why my question still stands: does the above
three-strikes operation safely take care of any collation
issues that may currently exist in a database ?

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: ON CONFLICT and WHERE
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: Q: fixing collation version mismatches