Forums PostgreSQL.fr

albourg

Membre

collation

Bonjour,

j'ai un master sous centos 7, postgresql 15.7. (x86_64)
J'ai un slave sous red hat 9, postgresql 15.8. (x86_64)

J'ai un warning sur le slave:

[postgres@PR-DRS-DBC-01 log]$ psql
WARNING:  database "postgres" has a collation version mismatch
DETAIL:  The database was created using collation version 2.17, but the operating system provides version 2.34.
HINT:  Rebuild all objects in this database that use the default collation and run ALTER DATABASE postgres REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.
psql (15.8)
Type "help" for help.

C'est grâve docteur?

Apparemment il faudrait logiquement changer la collation du master, mais je ne suis pas sur que je peux encore updater centos 7. Du nouveau matos est prévu ... pour l'an prochain.
Par contre, autre idée, est-il possible d'avoir la liste des tables qui n'utilisent PAS la collation par défaut et de la forcer (je crains le downtime).
Et si je ne fais rien sur le master, et que je lance la procédure sur le slave en cas de désastre, quel sera le downtime?

Merci.

dverite

Membre

Re : collation

C'est grâve docteur?

Avoir glibc 2.17 sur le primaire versus 2.34 sur  le secondaire, oui c'est très ennuyeux si les collations utilisées sur les colonnes texte sont "linguistiques", par exemple fr_FR.UTF8. Un index créé avec les règles de tri de glibc 2.17 sur le primaire, va produire des résultats faux quand il sera utilisé sur le secondaire avec glibc 2.34.

En règle générale, la configuration où le primaire et le secondaire ont des versions de systèmes différents n'est pas viable.

Et si je ne fais rien sur le master, et que je lance la procédure sur le slave en cas de désastre, quel sera le downtime?

Dans la réplication physique, il n'est pas possible d'écrire sur le secondaire, donc cette procédure n'est pas envisageable.

Si c'était à faire sur un primaire, ce ALTER DATABASE est très rapide mais il faut comprendre que tout ce qu'il fait, c'est prendre le numéro de version de glibc et exécuter

UPDATE pg_database SET datcollversion=<numéro de version> WHERE oid=<oid de la base>

C'est fait pour signaler à Postgres qu'on a bien "Rebuilt all objects in this database that use the default collation" et que ce n'est pas plus peine de nous remonter cette alerte.
Postgres lui-même n'a hélas pas de commande lui permettant ni de trouver ni de gérer automatiquement tous les objets qui ont besoin d'être rafraîchis suite à upgrade de collation.

---

@DanielVerite
http://blog-postgresql.verite.pro/

albourg

Membre

Re : collation

Ce n'est pas clair.

Le slave ne sert qu'en cas de désastre. Si on le promeut et que directement après, on recrée les indexes, les bases seront-elles consistentes? (sans quoi ce slave ne sert à rien).
Sinon, comment peut se passer le passage sur un nouveau matos (rh9) sans devoir faire un pg_basedump? (la db fait 2Tb, les downtimes sont limités).
Et je suppose que lorsque l'on fera cela, le slave devra être rebuildé.

dverite

Membre

Re : collation

Oui c'est bon si sur le secondaire-devenu-primaire, les index concernés sont recréés avant d'être utilisés dans des requêtes.
En pratique c'est souvent suffisant. En théorie ça ne gère pas tous les cas. Il peut y avoir des dépendances plus subtiles sur les collations, par exemple une contrainte CHECK column BETWEEN 'valeur1' AND 'valeur2', ou encore du PARTITION BY RANGE avec des valeurs texte, ou une contrainte CHECK avec une expression régulière dont le résultat dépend de la version d'Unicode.. Idéalement il faut vérifier les schémas des bases pour identifier ce genre de problème.

Le passage à glibc-2.28 a occasionné des différences de comparaison sur des chaînes de caractères tout à fait basiques.
Cf https://blog-postgresql.verite.pro/2018 … grade.html

---

@DanielVerite
http://blog-postgresql.verite.pro/

albourg

Membre

Re : collation

le message indique

HINT:  Rebuild all objects in this database that use the default collation and run ALTER DATABASE postgres REFRESH COLLATION VERSION

Est-ce que ça veut dire que si je force la collation

CREATE DATABASE "scratch"
  WITH OWNER "postgres"
  ENCODING 'UTF8'
  LC_COLLATE = 'en_US.UTF-8'
  LC_CTYPE = 'en_US.UTF-8';

je n'aurai rien à faire lors de la récupération d'un backup sun un OS plus récent? Ca m'intéresse de savoir comment éviter de reconstruire les indexes lors des (inévitables) migrations.

Merci.

rjuju

Administrateur

Re : collation

Non, le seul moyen de ne pas avoir a reconstruire les indexes en cas de mise a jour de glibc / icu est d'utiliser une collation qui ne depend pas de ces librairies, donc la collation C.

---

Julien.
https://rjuju.github.io/