Forums PostgreSQL.fr

sihem_info

Membre

collation database différente aprés migration

Bonjour a tous ,

j'ai fait une migration du serveur PostgreSQL du version 9 vers la version 11

après la migration j'ai constaté que la collation au niveau du serveur source est différent au collation du serveur migré (English_United States.1252--->French_France.1252)
j'ai fait la migration a travers un simple

pg_dumpall >all export.sql

Pourquoi ma commande pg-dumpall n 'a pas conservé la collate du serveur source

                                                   List of databases
         Name         |  Owner   | Encoding |          Collate           |           Ctype            |   Access privileges
----------------------+----------+----------+----------------------------+----------------------------+-----------------------
 Orchestra_TES| postgres | UTF8     | English_United States.1252 | English_United States.1252 |
produit            | postgres | UTF8     | English_United States.1252 | English_United States.1252 |
produit1        | postgres | UTF8     | English_United States.1252 | English_United States.1252 |
produit22        | postgres | UTF8     | English_United States.1252 | English_United States.1252 |
 postgres             | postgres | UTF8     | English_United States.1252 | English_United States.1252 |
 template0            | postgres | UTF8     | English_United States.1252 | English_United States.1252 | =c/postgres          +
                      |          |          |                            |                            | postgres=CTc/postgres
 template1            | postgres | UTF8     | English_United States.1252 | English_United States.1252 | postgres=CTc/postgres+
                      |          |          |                            |                            | =c/postgres
 testoa               | postgres | UTF8     | English_United States.1252 | English_United States.1252 | 

après migration

                                          List of databases
     Name     |  Owner   | Encoding |      Collate       |       Ctype        |   Access privileges
--------------+----------+----------+--------------------+--------------------+-----------------------
 Lyon         | postgres | UTF8     | French_France.1252 | French_France.1252 |
 Produit22        | postgres | UTF8     | French_France.1252 | French_France.1252 |
 produit    | postgres | UTF8     | French_France.1252 | French_France.1252 |
produit1 | postgres | UTF8     | French_France.1252 | French_France.1252 |
 postgres     | postgres | UTF8     | French_France.1252 | French_France.1252 |
 template0    | postgres | UTF8     | French_France.1252 | French_France.1252 | =c/postgres          +
              |          |          |                    |                    | postgres=CTc/postgres
 template1    | postgres | UTF8     | French_France.1252 | French_France.1252 | =c/postgres          +
              |          |          |                    |                    | postgres=CTc/postgres 

cordialement

Dernière modification par sihem_info (29/03/2021 16:04:31)

dverite

Membre

Re : collation database différente aprés migration

Les bases template0 et template1 de la destination étaient déjà créées avant la restauration du dump et elles avaient déjà la locale French_France.1252. Les bases nouvellement créés dans cette instance prennent par défaut le lc_collate/lc_type de la base template1 de leur propre instance.

On peut se demander pourquoi ces options ne sont pas spécifiées à l'intérieur du dump dans les commandes CREATE DATABASE.
Vraisemblablement, c'est pour ne pas forcer la main si c'est volontairement que le cluster de destination a des locales différentes.

Pour avoir la même chose que l'instance de départ, il aurait fallu initialiser le cluster destination (c.a.d le répertoire PGDATA avec initdb) avec les options --lc-collate et --lc-ctype (ou l'option --locale éventuellement qui aurait été plus générale) en donnant spécifiquement "English_United States.1252" comme valeurs. Ou pré-créer les bases (il y a plusieurs solutions dans le détail, mais toutes reviennent à faire plus de choses à la main en gros).

---

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