Vous n'êtes pas identifié(e).
duple a écrit :Sinon, est ce que quelqu'un connait quelles sont les actions qui peuvent engendrer l'erreur ERROR: query returned no rows ?
À priori une clause INTO STRICT dans une commande plpgsql.
>>> A j'ai que INTO dans mes requêtes mais pas STRICT
duple a écrit :Ok, le bout de code suspect dans la fonction :
Suspect ou coupable ? Le message d'erreur devrait donner des informations sur la partie exacte du code retournant l'erreur.
Bah en fait, c'est aussi un souci, car tu vois le message d'erreur il n'indique pas la requête qui pose problème. Le message dit juste : ERROR: queyr returned no rows SQL state: P0002 Context: PL/pgSQL function fusion_temp.algo_fusion(bigint,bigint,bigint,text,text,bigint,bigint,bigint,boolean,boolean,integer)
Sinon, est ce que quelqu'un connait quelles sont les actions qui peuvent engendrer l'erreur ERROR: query returned no rows ?
Et sinon, si on lance PG en mode mono utilisateur avec un certain niveau de debug çà dit quoi, le message est peut être un peu plus clair ou c'est le même que dans le log ?
postgres --single -D /path_pgdata/data -d 3 la_base
Par curiosité le fichier WAL fait combien de mega ? Est ce qu'il est compressé ?
Ok, le bout de code suspect dans la fonction :
IF ((p_debut_i <= p_debut_j) AND (p_fin_i >= p_fin_j))THEN
RAISE NOTICE 'debut FUS 3 idtli % deb i % fini % idtlj % debj % finj %',p_id_temp_i,p_debut_i,p_fin_i,p_id_temp_j,p_debut_j,p_fin_j;
v_date1 := p_debut_j::date;
v_date2 := p_debut_j::date +1;
RAISE NOTICE 'SELECT id_temp INTO v_id_temp FROM t_temp WHERE pers = % AND proj = % AND id_op = % AND deb > % AND deb < % AND id_temp <> % AND duree > 0 LIMIT 1',p_pers_j,p_pers_j,p_op_j,v_date1,v_date2,p_id_temp_j;
--C'EST ICI LE CODE SUSPECT QUI PETE
SELECT id_temp INTO v_id_temp FROM t_temp WHERE pers = p_pers_j AND proj = p_proj_j AND id_op = p_op_j AND deb > v_date1 AND deb < v_date2 AND id_temp <> p_id_temp_j AND duree > 0 LIMIT 1;
-- Pour certaine données l'execution de la fonction s'arrete ici et renvoie l'erreur ERROR : query returned no rows
raise notice 'v_id_temp %',v_id_temp;
IF (v_id_temp is not null) THEN
p_qte_j := COALESCE(p_qte_j,0);
EXECUTE 'UPDATE '||v_tfusion_temp_i||' SET qte = qte + '||p_qte_j||' WHERE id_temp = '||v_id_temp;
EXECUTE 'UPDATE t_temp SET qte = coalesce(qte,0) + '||p_qte_j||', com=''fusion temp: rajout qte du temp '||p_id_temp_j||' algo fus'' WHERE id_temp = '||v_id_temp;
PERFORM fusion_temp.update_quantity3(p_proj_j, p_op_j, p_id_temp_j, v_id_temp);
END IF;
EXECUTE 'DELETE FROM '||v_tfusion_temp_j||' WHERE id_temp = '||p_id_temp_j;
PERFORM fusion_temp.update_quantity_unicite(p_proj_j, p_op_j, p_id_temp_j, null::integer, null::integer, 'delete'::text);
PERFORM fusion_temp.delete_temp(p_id_temp_j,p_id_temp_i,'algo fus');
INSERT INTO fusion_temp.algo_debug(idtli,debi,fini,id_sysi,idtlj,debj,finj,id_sysj,login,algo_trouve,date_recherche) VALUES (p_id_temp_i,p_debut_i,p_fin_i,p_id_sys_i,p_id_temp_j,p_debut_j,p_fin_j,p_id_sys_j,p_pers_i,'algo fus',p_debut_i::date);
RAISE NOTICE 'fin FUS 3 idtli % deb i % fini % idtlj % debj % finj %',p_id_temp_i,p_debut_i,p_fin_i,p_id_temp_j,p_debut_j,p_fin_j;
RETURN 3;
Salut,
Si çà peut aider, existe un logiciel "Navicat" qui permet de se connecter sur plusieurs SGBD, tel que Oracle, PG, Mysql, ... et on peut exécuter des requêtes dedans, on peut également exporter les données sous plusieurs format : le xml y compris. Tu peux même paramétrer çà pour que çà se lance en tache planifiée, super le soft non 
Bonjour,
Je travaille sur PG9.6 environnement linux et je rencontre l'erreur suivante lors de l'execution d'une fonction -> "ERROR: query returned no rows" .
Vraiment je ne comprend pas l'intérêt de ce message d'erreur, pourquoi la requête ne renvoie t elle seulement pas une ligne vide avec valeur null si pas d'enregistrement, d'ailleurs c'est ce qui est le fonctionnement normale il me semble.
J'ai une requête je la teste avec un truc simple genre:
do $$
declare
x bigint;
begin
SELECT col_x INTO x
FROM table
WHERE col_a <> val_1
AND col_b = 'val_2'
AND col_c = val_3
AND col_d = val_4
AND col_e > 'val_51'::date
AND col_e < 'val_51'::date
AND col_f > 0
LIMIT 1;
raise notice 'x %',x;
end;
$$ language plpgsql;
La pas de problème la requête ne retourne rien , on a pas d'erreur , on a comme résultat :
NOTICE: x <NULL>
Maintenant, je prend cette requête je la place dans une autre fonction bien plus complexe qui traite plusieurs lignes d'enregistrement.
Puis je tombe sur cette erreur que je ne comprend pas ERROR: query returned no rows
Pourquoi cette erreur ? Et comment la résoudre ? Il semble que la fonction pète lors de l’exécution de cette même requête (sachant que défois çà passe défois çà pète).
Please help !
Quelqu'un une idée la dessus ?
Merci
Merci à vous pour ces explications.
Çà serait plutôt quand même sympa si on pouvait lors d'élaboration de fonctions plpgsql d'activer ou de désactiver ce comportement INSENSITIVE de la boucle FOR.
rjuju> Si je comprend INSENSITIVE explique le fait que la mise à jour dans la boucle n'est pas perceptible durant la boucle (dans les prochaines itérations) ?
Et WHERE CURRENT OF cursor_name met à jour la ligne sur laquelle le curseur pointe, mais cette modification ne sera pas évaluer à la prochaine itération puisque le curseur est INSENSITIVE ?
C'est çà ?
Salut à tous,
Merci pour ces réponses.
dverite > C'est vrai qu'un simple UPDATE pourrait sans doute faire les mises à jour nécessaires dans cet exemple mais en réalité il existe d'autres traitement à faire qui nécessite de passer par une boucle FOR. Ici l'exemple ne le montre pas car c'est plus simplifié pour décrire le besoin.
rjuju > Interessant, pourrais tu plus expliquer et décrire le sujet stp (WHERE CURRENT OF et curseur insensitive)?
Oui c'est çà, la modification n'est pas ré évaluer dans la suite des itérations.
Voilà pourquoi jai du passer par un traçage pour faire connaitre au boucle les changements de valeurs.
Mais est ce que ce principe de traitement de boucle for avec un select est valable pour tout sgbd ?
En guise d'information:
Pour contourner le problème j'ai du à chaque update fait dans la 2ème boucle > tracer la ligne modifiée par son id puis la valeur modifiée. Et au passage de boucle, vérifier si la ligne traitée dans la boucle figure dans le traçage, si oui mettre à jour l'élément modifiée par sa bonne valeur. Re vérifier si le test dans 2 ème boucle coincide toujours avec les nouvelles valeurs. Du coup les éléments sont à jour au fur et à mesure des itérations.
Pour ajouter je veux que les modifications faites dans la 2ème boucle, soient perceptible au niveau de la 1ère boucle :
itération i=1 de la première boucle , on fait une modification dans la 2ème boucle, donc dans la 2ième itération (et plus) de la première boucle le update fait (dans 2ème boucle) lors de la première itération (1ère boucle) soit pris en compte (valeur mise à jour dans les itérations qui suivent)
Normalement çà devrait être çà non ?
Oui, je veux que lorsqu'on fait une modification dans la boucle , cette modification sera tout de suite aperçu lors des prochaines itérations dans la boucle.
Pour plus d'explication, une autre façon d'approche c'est que :
on a une valeur initiale par exemple : x = 2 , avant d'entrer dans la boucle. Puis on entre en boucle FOR : x vaut 2 toujours , disons maintenant que durant les traitements effectués dans la boucle FOR, on fait un update de x , x est maintenant égale à 3 normalement (c'est ce qu'on veut); mais, on constate que durant le parcours de boucle x est toujours = 2 mais pas à 3. Les modifications ne sont elles pas prise en compte instantanément dans une boucle ? Ou faudrait il attendre que le boucle soit fini pour prendre en compte les modifications ? Comment on peut contourner cela ?
Bonjour,
Je travaille sous PG9.6 environnement linux.
J'ai une fonction qui effectue des modifications de table avec un parcours de boucle.
En gros: je crée une table temporaire contenant des données pour simplifier disons :
La table T1 contient idt1, dateDeb_t1, dateFin_t1 (la table est remplie de données)
Par ailleurs, j'ai aussi une autre table physique non temporaire T2, avec T2 = idt2, dateDeb_t2 et dateFin_T2
Le principe est le suivant :
Je parcours les données de T1 comme suit: à chaque itération (ligne d'enregistrement) trouvée dans T1 je vérifie si il existe une certaine correspondance avec des lignes de T2 : s'il y a correspondance alors je modife dateDeb_T2 par dateFin_T1 pour la ligne (itération) en question idt1.
Pour simplifier on a comme suit :
FOR x,y,z IN SELECT idt1, dateDeb_t1, dateFin_t1 FROM T1
LOOP -- Je parcours une à une les lignes de T1
FOR a,b,c IN SELECT idt2, dateDeb_t2, dateFin_T2 FROM T2 WHERE dateDeb_t2 >= y AND dateDeb_t2 < z-- ici je verifie s'il existe la "correspondance"
LOOP
-- Pour chaque ligne T2 comprise dans la ligne en cours T1 : modifier dateDeb_T2 par dateFin_T1
-- C'est ici le cas intéressant : le pourquoi du comment ???
UPDATE T2 SET dateDeb_T2 = z
WHERE idt1 = a;
END LOOP;
END LOOP;
Le souci est que en exécutant cette fonction, elle tourne mais en vérifiant, les données ne sont pas à jour durant la boucle. C'est à dire je modifie dans le cas "pourquoi du comment" dateDeb_t2 mais pourtant au fur et à mesure du passage d'itération dans les boucles les nouvelles dateDeb_t2 ne sont pas à jour mais reste toujours la valeur initiale.
Sauriez vous pourquoi et comment corriger le fait que les valeurs initiales ne sont pas modifiées au fur et à mesure de la boucle.
Je précise que le type de dateDeb et dateFin joué ici est du timestamp without time zone, est qu'il y a lien la -dessus ?
Merci de votre attention et espérant qu'il y aura des réponses
C'est vrai merci , çà à resolu le problème
Bonjour,
J'utilise pg 9.6.
J'ai le petit script ci-dessous:
Do $$
DECLARE
v_time timestamp;
v_time_end timestamp;
BEGIN
SELECT current_timestamp INTO v_time;
v_time_end := v_time + interval '5 seconds';
LOOP
SELECT current_timestamp INTO v_time;
RAISE NOTICE 'v_time : % ---- v_time_end : %',v_time, v_time_end;
EXIT WHEN v_time> v_time_end;
END LOOP;
END;
$$ LANGUAGE plpgsql;
Quelqu'un peut me dire pourquoi ce script rentre dans une boucle infinie et la condition EXIT WHEN v_time> v_time_end; n'est pas prise en compte.
Plus précisement la valeur v_time n'est pas raffraichier et SELECT current_timestamp INTO v_time à l'interieur du boucle n'est pas prise en compte ?
Merci de votre attention
Vous pouvez toujours tester sur une base de test avant.
Sinon le plus simple à mon avis est de faire direct un dump sur 9.5 et restore sur 10
Bonjour,
Est ce vraiment les file system dans base (tablespace) qui ont augmentés ? Peut être que c'est autre chose (les wal peut être)
Essayez de refaire l'opération mais cette fois ci avec pg_repack => c'est similaire à du vacuum full + reindex mais sans pose de verrou.
Merci pour la reponse , ah oui on peut faire un returning sur l'update !!
Merci
Bonjour,
j'ai une requête du genre :
Si machin1 n'existe pas
INSERT INTO machin1
INSERT INTO machin 2 VALUES (curval_sequence_de_machin1)
sinon (machin1 existe)
UPDATE machin1
INSERT INTO macin2 VALUES (id_machin1,...)
Fin Si
Maintenant j'aimerai remplacer ces instructions par un simple UPSERT
Genre:
INSERT INTO machin1
ON CONFLICT ON CONSTRAINT la_contrainte_unicite DO
UPDATE machin1
Mais du coup comment faire là pour intégrer également INSERT INTO machin2 ?
En effet le repertoire pg_xlog a commencé à se remplir hier mais je ne sais pas si çà en est la cause ou pas. Pour y remedier on a mit archive_commande = /bin/true pour libérer l'espace. Un dump regulier est lancé toutes les nuits.
Sauriez vous donc quelle pourrait être la cause de la disparition de ce wall ?
la vrai question et donc pourquoi et comment le wall ne serait plus présent alors que dans archive_status il y aurait un wall.ready ??
Merci pour vos réponses,
pitpoule , ruizsebastien > réfléchis comme tel je pense que vous aviez peut être raison, mais je ne vois pas comment expliquer qu'un wall.ready est présent SANS le wall dans pgxlog, alors que c'est de part le wall qu'il detecte qu'il fait un .ready et par la suite un .done lorsque le wall sera copié ???
