Vous n'êtes pas identifié(e).
Pages : 1
Bonjour
Merci pour l'information, je suis effectivement passé à côté de cette note lors de l'upgrade debian. Et je fais effectivement des pg_upgradecluster -m upgrade car nous avons des tables très volumineuses. Tout s'explique maintenant.
Merci beaucoup pour vos réponses.
Cordialement
Olivier
Bonjour
Merci beaucoup pour ce retour. En effet il semble que l'index soit corrompu.
explain select sponsor, sponsor_email from truites.sponsor s where s.sponsor IN ('AAPPMA_Greoux', 'Univ._Antilles')
QUERY PLAN |
----------------------------------------------------------------------------+
Seq Scan on sponsor s (cost=0.00..10.88 rows=2 width=296) |
Filter: ((sponsor)::text = ANY ('{AAPPMA_Greoux,Univ._Antilles}'::text[]))|
explain select sponsor, sponsor_email from truites.sponsor s where s.sponsor IN ('Univ._Antilles')
QUERY PLAN |
------------------------------------------------------------------------------+
Index Scan using sponsor_pkey on sponsor s (cost=0.14..8.16 rows=1 width=296)|
Index Cond: ((sponsor)::text = 'Univ._Antilles'::text) |Cela explique la différence de comportement entre les deux requêtes...
Et REINDEX n'aboutit effectivement pas.
Nous avons effectivement fait une mise à jour pg 9 => pg 10 => pg 11 à l'occasion d'une mise à jour système (debian, maintenant en 10.9).
J'utilise la commande pg_upgradecluster pour faire la migration.
Mais difficile de savoir à quand remonte le problème et si cela a effectivement un lien avec les mises à jour.
Il n'y a a priori que ces deux clés qui posent problème. Le fait que le caractère '_' soit en question alors qu'il s'agit d'un caractère spécial du LIKE m'interpelle. Mais nous avons d'autres clés qui contiennent ce caractère qui elles ne posent pas problème. Donc...
En tout cas, supprimer ces enregistrements et faire un REINDEX devrait résoudre le problème. Au pire je peux tout régénérer. Je voulais surtout comprendre ce comportement, mettre une explication technique.
Merci beaucoup.
Olivier
Bonjour
Nous avons observé un comportement très étrange de postgreSQL (v. 11.12) avec une table d’une de nos bases de données :
CREATE TABLE truites.sponsor (
sponsor varchar(30) NOT NULL,
sponsor_email varchar(100) NULL,
sponsor_address varchar(300) NULL,
sponsor_tel varchar(15) NULL,
sponsor_url varchar(100) NULL,
CONSTRAINT sponsor_pkey PRIMARY KEY (sponsor)
);Le problème porte sur un caractère '_' dans la clé primaire sponsor, dont nous ignorons comment il est stocké (encodé ?) par postgres.
NB : j'ai utilisé le champ sponsor_email pour bien différencier des enregistrements.
select sponsor, sponsor_email from truites.sponsor s where s.sponsor LIKE 'Univ.\_Antilles'
sponsor |sponsor_email |
--------------+-------------------+
Univ._Antilles|has real underscore|
select sponsor, sponsor_email from truites.sponsor s where s.sponsor LIKE 'Univ._Antilles'
sponsor |sponsor_email |
--------------+-------------------+
Univ._Antilles| |
Univ._Antilles|has real underscore|
select md5(sponsor), sponsor_email from truites.sponsor s where s.sponsor LIKE 'Univ._Antilles'
md5 |sponsor_email |
--------------------------------+-------------------+
671fa31dcf8193915bf3de0e039f428c| |
671fa31dcf8193915bf3de0e039f428c|has real underscore|La première requête montre qu'il existe une valeur de clé qui contient un caractère '_'
La deuxième requête montre qu'il existe une valeur de clé qui contient un caractère qui ressemble a un '_' mais qui n'en est pas un sinon on aurait un conflit de clé primaire.
La troisième requête montre que pourtant ces deux caractères sont identiques puisque le md5 est le même.
Nous avons exactement le même comportement avec une autre clé 'AAPPMA_Greoux'.
De plus nous pouvons observer ceci avec l'utilisation de la clause IN :
select sponsor, sponsor_email from truites.sponsor s where s.sponsor IN ('AAPPMA_Greoux')
sponsor |sponsor_email |
-------------+------------------------+
AAPPMA_Greoux|has real underscore|
select sponsor, sponsor_email from truites.sponsor s where s.sponsor IN ('Univ._Antilles')
sponsor |sponsor_email |
--------------+-------------------+
Univ._Antilles|has real underscore|
select sponsor, sponsor_email from truites.sponsor s where s.sponsor IN ('AAPPMA_Greoux', 'Univ._Antilles')
sponsor |sponsor_email |
--------------+-------------------+
AAPPMA_Greoux | |
Univ._Antilles| |
Univ._Antilles|has real underscore|
AAPPMA_Greoux |has real underscore|Comment se fait-il que les enregistrements ressortent quand on a deux valeurs dans la clause 'IN' d'autant qu'ils ne ressortent pas quand on n'a qu'une valeur ?
Nous ne savons pas du tout comment nous nous sommes retrouvés dans cette situation.
La valeur de ce champ est renseigné via une interface Web de type CRUD d'un site php.
Quelqu'un aurait-il une explication à ce comportement ? Il y a-t-il quelque chose qui nous échappe ?
Merci d'avance pour votre aide
Bien cordialement
Olivier
Pages : 1