Discussion :

[IsaM59]

Bonjour,

Pour les besoins d'un projet COBOL/Postgres, j'ai créé un curseur qui me renvoie 6 lignes de 2 champs.
Lorsque je descend ce curseur par une boucle , l'application me renvoie le message d'erreur suivant et se ferme: double free or corruption (out)

[1] 5438 IOT instruction (core dumped) ./runstat

La requète du curseur fonctionne lorsque je l'exécute directement dans la base, je ne comprend pas pourquoi j'ai ce message, sachant qu'une partie des données est bien récupérée (j'ai déstructuré la boucle pour exécuter le fetch ligne par ligne, il s'arrète à mi chemin (3 lignes lues pour 6 lignes à lire)).
Voici la requête:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
SELECT r.REGION_NUM, 
                          COUNT(c.UUID_CUSTOMER) AS NB_CUSTOMER
                 FROM BOBO_REGION r JOIN CUSTOMER c
                 ON SUBSTRING(c.CUSTOMER_ZIPCODE FROM 1 FOR 2) 
                       = r.REGION_CODEDEP
                 WHERE c.CUSTOMER_ACTIVE IN ('1','0')       
                 GROUP BY r.REGION_NUM
                 ORDER BY r.REGION_NUM;

Et le résultat depuis la base:

region_num	nb_customer
1	1
7	1
8	1
10	1
11	1
13	1

Rien de bien méchant...
Auriez vous des pistes pour expliquer et corriger ce qui doit l'être pour aller jusqu'au bout de ma boucle sur le fetch?

[Michel.Priori]

Bonjour,

Visiblement le problème vient plutôt du curseur.
En quel langage est-il programmé ? pl-sql ?

Ce que je suspecte : lire une ligne inexistante.
Dans ce cas c'est la condition de sortie qui serait en cause.

Sinon, faire une table temporaire du résultat (stabilisation du résultat) et faire une requête sur cette table en jouant avec LIMIT
https://www.postgresql.org/docs/curr...ies-limit.html

[IsaM59]

Bonjour.

Merci pour votre réponse.
Cependant, j'ai du mal à la comprendre; comment un curseur peut il ramener une ligne inexistante?
Cela se passe au milieu de la lecture des résultats, ce n'est donc pas la fin de curseur qui serait mal gérée.

Merci pour l'astuce LIMIT pour éviter de déstructurer ma boucle FETCH. Je n'y avais pas pensé.

Sinon, oui, je travaille en pl-sql.

[SQLpro]

Si votre curseur est "live" et que vous n'avez pas mis de ORDER BY, les lignes peuvent se déplacer au gré des UPDATEs concurrent et ce type d'erreur peut apparaitre si le système croyait trouver une ligne qui s'est finalement déplacée...

A +

[escartefigue]

bonjour,

Autre solution, utiliser une isolation "RR" pour que les lectures soient "répétables", mais bien sûr, c'est au détriment des threads concurrents.
Voir ICI


À ce propos :

Pour les besoins d'un projet COBOL/Postgres, j'ai créé un curseur qui me renvoie 6 lignes de 2 champs.

Il s'agit de 6 lignes de deux colonnes, les champs n'ont rien à voir avec la BDD : ce sont les zones d'un formulaire de saisie ou d'un état.


Enfin, la fonction substring sur le prédicat de jointure rend celui-ci non sargable : aucun index n'est éligible, les performances peuvent s'en ressentir.
Ce besoin est probablement symptomatique d'une erreur de modélisation.

[IsaM59]

Merci pour vos retours.
D'abord il y a un order by dans la requête du curseur.
Ensuite, je suis la seule à utiliser la base lorsque je lis les données renvoyées par le curseur. Il n'y a donc pas de concurrence avec une autre action sur la table, pas de mise à jour ni de lecture.
Enfin, le substring est là pour isoler le code département du code postal des clients.

[escartefigue]

Enfin, le substring est là pour isoler le code département du code postal des clients.

Ce qui est une mauvaise idée : les deux premiers caractères du code postal correspondent souvent au département, mais pas toujours, il y a de nombreuses exceptions !

Voyez ICI


Ça confirme l'erreur de modélisation.