Vous n'êtes pas identifié(e).
Bonsoir,
je viens d'installer PostgreSQL 10 et lorsque je veux ajouter un nouveau serveur (avec pgAdmin4), j'ai systématiquement le message d'erreur suivant qui apparait: "'utf8' codec can't decode byte 0xe9 in position 42: invalid continuation byte"
J'ai beau chercher sur le net, beaucoup de personnes se plaignent de ce message, mais je n'ai trouvé aucune réponse qui puisse résoudre le problème.
Quelqu'un saurait-il me dire ce qu'il convient de faire pour résoudre le problème ?
Merci d'avance.
Hors ligne
Je suppose que vous voulez vous connecter à une instance postgres sous windows, et que le nom de la base contient un "é".
Le problème est que l'octet 0xe9 ne représente effectivement pas un caractère valide en utf8, mais en cp1252 cela correspond au caractère "é".
Il faudrait remonter le problème aux développeurs de pgadmin4, en leur précisant comment reproduire le problème (environnement client et serveur, encodage de la base etc), après vous être assuré que vous disposez bien de la dernière version de pgAdmin4.
Julien.
https://rjuju.github.io/
Hors ligne
Merci pour votre réponse rapide !
J'ai effectivement oublié de préciser que je travaille sous Windows (8.1 64 bits pour être plus précis) et que la version de pgAdmin4 est la version 2.0 (c'est donc bien la dernière).
Pour le nom de la base, j'en ai testé plusieurs, dont TOTO ... et j'ai le même message d'erreur à chaque fois.
Je vais donc remonter le problème, mais puisque c'est systématique, ce serait étonnant qu'ils ne soient pas déjà au courant (et donc je dois sans doute rater une étape, mais je ne vois pas laquelle). J'ai fait le tour des préférences dans le menu, mais je n'ai rien vu qui pourrait expliquer ce problème.
En fait, il suffit de lancer pgAdmin4, créer un nouveau serveur, le nommer TOTO (ou un tout autre nom), lui attribuer l'adresse localhost et lui affecter un mot de passe (peu importe lequel, toto par exemple). En voulant sauvegarder, le message d'erreur en question s'affiche.
Hors ligne
Avez-vous une stack trace de cette erreur ? Je pense que le problème ne vient pas du nom que vous donnez au serveur mais des données contenues dans celui-ci, par exemple un nom d'utilisateur ou de base de donnée contenant un "é", en utilisant un encodage différent qu'utf8. Pour ma part je ne sais malheureusement pas quelles sont les informations récupérées au moment de l'ajout du serveur, mais les développeurs devraient pouvoir isoler le problème rapidement.
Julien.
https://rjuju.github.io/
Hors ligne
Il faudrait vérifier les messages d'erreur côté serveur. De toute façon, c'est toujours la chose à faire quand quelque chose dysfonctionne et qu'on n'a pas d'idée sur la raison.
Sinon une chose à essayer serait
lc_messages = 'C'
dans la configuration serveur. L'idée est que le caractère "é" encodé en iso-latin pourrait faire partie d'un message d'erreur encodé comme ça, justement parce que lc_messages indiquerait de faire ça, alors que pgAdmin4 les attendrait en utf-8.
En mettant 'C' , les versions non traduites des messages (donc compatibles utf-8) seront produites.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Bonsoir,
merci pour vos messages.
Mon problème survient au départ, au moment de créer un serveur. Il est vide à ce stade.
L'erreur est tellement énorme et récurrente que je dois rater une étape je suppose mais je ne vois pas laquelle.
Je ne comprends pas non plus ce que vous voulez que je fasse.
Hors ligne
pgAdmin et le serveur PostgreSQL sont deux logiciels séparés qui communiquent par réseau. Même s'ils sont installés sur la même machine.
Quand on "crée un serveur" sous pgAdmin, on indique où se trouve PostgreSQL et comment le joindre, et aussitôt il chercher à s'y connecter, et c'est là apparemment que l'erreur survient.
Biensûr tout le monde n'a pas cette erreur sinon les développeurs n'auraient même pas diffusé pgAdmin dans cet état, il y a une variabilité lié à l'environnement là-dessous. Vu que l'erreur concerne l'encodage d'un E accentué, ça oriente clairement vers une histoire d'environnement francophone versus anglophone.
PostgreSQL a un fichier de configuration qui s'appelle postgresql.conf et je suggère d'aller vérifier et changer le paramètre lc_messages dans ce fichier.
Par ailleurs il a des fichiers de log qui consignent les erreurs qui surviennent et je suggère aussi de regarder s'ils mentionnent qq chose au moment de l'erreur.
L'emplacement des logs est spécifié dans postgresql.conf, ça peut atterrir aussi dans le journal de windows lisible avec l'observateur d'évènement de windows.
Dernière modification par dverite (19/10/2017 12:47:05)
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Bonsoir,
merci pour ces explications claires.
J'ai modifié le fichier postgresql.conf comme proposé, mais rien n'y fait, l'erreur survient toujours.
J'ai même modifié les 3 autres lignes 'lc_monetary', 'lc_numeric' et 'lc_time' (initialement configurées avec 'French_France.1252').
Pour les logs, à chaque tentative j'ai les lignes suivantes qui sont mémorisées: par exemple pour la dernière tentative:
2017-10-19 20:23:37.297 CEST [6820] FATAL: authentification par mot de passe échouée pour l'utilisateur « postgres »
2017-10-19 20:23:37.297 CEST [6820] DÉTAIL: Mot de passe ne correspond pas pour l'utilisateur postgres :
La connexion correspond à la ligne 82 du pg_hba.conf : « host all all ::1/128 md5 »
Hors ligne
C'est intéressant qu'il y ait une erreur avec un é (sur "échouée") en 1er caractère hors ASCII parce que ça correspond bien à l'idée que c'est le message d'erreur que pgAdmin n'arrive pas à gérer (en plus d'être écrit dans le log il est envoyé à pgAdmin qui en théorie devrait l'afficher s'il y arrivait).
Le message d'erreur est en français mais pourtant ne devrait plus l'être si lc_messages était positionné à C.
Vous êtes sûr d'avoir redémarré le service PostgreSQL après la modification?
Dans un second temps, il y a le problème que d'après cette erreur, un mauvais mot de passe est entrée dans pgAdmin pour l'utilisateur postgres. Pour éviter ça, vous pouvez éditer le fichier pg_hba.conf et mettre "trust" à la place de "md5", comme ça il ignorera le mot de passe. Il faut aussi recharger le service PostgreSQL, je ne sais plus comment on fait sous Windows, au pire un arrêt-relance.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
J'avais seulement arrêté et redémarré le programme pgAdmin, mais pas le service PostgreSQL.
Je viens donc de le faire ... et ça avance !
Le nouveau message d'erreur qui s'affiche correspond au problème de mot de passe:
"Unable to connect to server:
FATAL: password authentication failed for user "postgres""
Et dans le fichier de log:
2017-10-19 21:19:44.498 CEST [6524] LOG: database system was shut down at 2017-10-19 21:19:31 CEST
2017-10-19 21:19:44.519 CEST [4136] LOG: database system is ready to accept connections
2017-10-19 21:20:27.775 CEST [4180] FATAL: password authentication failed for user "postgres"
2017-10-19 21:20:27.775 CEST [4180] DETAIL: Password does not match for user "postgres".
Connection matched pg_hba.conf line 82: "host all all ::1/128 md5"
J'ai ensuite modifié le fichier pg_hba.conf comme proposé (ce qui est bizarre c'est que l'erreur est stipulée pour la partie IPv6 seulement dans le fichier) ... et là tout fonctionne à présent ! Le serveur a bien été créé !
Pour ce problème de mot de passe, comme c'est à la création du serveur, je suppose qu'il correspond à celui qu'on veut imposer (puisque je n'en avais pas rentré précédemment hormis celui du super-utilisateur (que j'ai essayé aussi, mais sans plus de succès)).
Je vais pouvoir avancer à présent ! Un grand merci à nouveau pour votre aide rapide et efficace !!
Hors ligne
L'erreur portant sur IPv6 indique que c'est bien une connection IPv6 faite par le client. Mais ce n'est pas très surprenant, pour beaucoup de systèmes maintenant localhost est alias de 127.0.0.1 et aussi de ::1. Le plus simple est d'utiliser explicitement 127.0.0.1 pour forcer IPv4 si nécessaire.
Pour le mot de passe, je m'attendrais à ce que soit le même que celui demandé à l'installation de PostgreSQL.
Reste que pgAdmin ne sait apparemment pas se débrouiller avec un message d'erreur non utf-8 au moment de l'établissement de la connexion, ça a l'air d'être un bug qui mériterait de leur être signalé s'il n'est pas déjà enregistré dans leur outil:
https://redmine.postgresql.org/projects/pgadmin4
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Bonsoir,
C'est chose faite, je leur ai signalé le bug en question 
Hors ligne
