Vous n'êtes pas identifié(e).
Pages : 1
Merci gleu pour cette réponse.
Mais on était un peu insatisfait quand même de devoir préparer puis exécuter une requête. Alors on a cherché sur le net ...
Et on a trouvé une solution (incomplète... ) mais qui marche une fois complétée.
C'est sur http://archives.postgresql.org/pgsql-bu … g00039.php
Bug #5489 déclaré et réparé par "Alexander" <goal81@gmail.com> avec réponse de Michael Meskes <meskes@postgresql.org>.
On se permet de compléter l'info :
Dans .../src/interfaces/ecpg/preproc/preproc.y changer la ligne :
returning_clause: RETURNING target_list
par la ligne :
returning_clause: RETURNING target_list ecpg_into
mais changer également la ligne d'instruction :
$$ = cat_str(2,make_str("returning"),$2);
par :
$$ = cat_str(3,make_str("returning"),$2,$3);
Ça compile et même ... ça fonctionne en plus !
Merci à tous ...
Bonjour,
Le pré-compilateur ecpg ne comprend pas la directive 'RETURNING ... INTO ...'.
Il semble ne pas admettre de variable hôte.
Exemple :
La requête suivante :
EXEC SQL INSERT INTO fremise
(resite, remach, redatech, renobord)
VALUES (:pRem->resite_tc:pRem->i_resite, :pRem->remach_tc:pRem->i_remach,
:pRem->redatech_tc:pRem->i_redatech, :pRem->renobord_l:pRem->i_renobord)
RETURNING renum INTO :pRem->renum_l:pRem->i_renum;
génère le code C suivant en passant dans le pré-compilateur ecpg :
{ ECPGdo(__LINE__, 0, 1, NULL, 0, ECPGst_normal, "insert into fremise ( resite , remach , redatech , renobord ) values ( $1 , $2 , $3 , $4 ) returning renum",
ECPGt_char,(pRem->resite_tc),(long)7 + 1,(long)1,(7 + 1)*sizeof(char),
ECPGt_int,&(pRem->i_resite),(long)1,(long)1,sizeof(int),
ECPGt_char,(pRem->remach_tc),(long)2 + 1,(long)1,(2 + 1)*sizeof(char),
ECPGt_int,&(pRem->i_remach),(long)1,(long)1,sizeof(int),
ECPGt_char,(pRem->redatech_tc),(long)10 + 1,(long)1,(10 + 1)*sizeof(char),
ECPGt_int,&(pRem->i_redatech),(long)1,(long)1,sizeof(int),
ECPGt_long,&(pRem->renobord_l),(long)1,(long)1,sizeof(long),
ECPGt_int,&(pRem->i_renobord),(long)1,(long)1,sizeof(int), ECPGt_EOIT, ECPGt_EORT);}
où la partie 'INTO' du RETURNING a disparu et où n'apparaît pas la variable pRem->renum_l ni son indicateur..
Le pré-compilateur renvoie l'erreur suivante :
sgbd_traitrans.o ... /usr2/filip/sources/stap/serveur/sgbd_traitrans.ec:1273: ERROR: syntax error at or near "INTO"
Est-il possible de modifier la pré-compilation afin de gérer cette clause ?
En vous remerciant par avance ...
Malheureusement non, le vacuum ayant duré 1h30, nous redoutions le temps du reindex!
Bonjour et encore merci pour vos réponses.
La version utilisée est 8.2, elle ne peut être changée, nous ne somme pas administrateur du serveur.
la valeur de max_fsm_pages est de 40 000 ce qui était suffisant avant le vacuum full ... et qui ne l'est plus depuis. un Notice en fin de vacuum journalier indique que le besoin augmente tous les jours: 46000, 72000, 90000, 125000.
Nous allons en augmenter la valeur.
Suite à vos conseils, nous pensons également mettre en oeuvre un autovacuum. Reste à régler ses paramètres.
Bonjour et merci beaucoup pour vos réponses.
Des vacuum sont effectués tous les jours sur la base. La table pg_locks ne contenait pas d'anciennes transactions. Par contre la base est en activité permanante (insert/update/delete/select) et il n'est pas possible d'interrompre le service.
Nous avons toutefois arrêté toutes les activités le temps d'un vacuum FULL, qui a duré 1 heure 1/2 et qui a rétabli la situation (plus de dead rows).
le résultat du vacuum journalier effectué le lendemain, alors que l'activité avait reprise, montre de nouveau quelques deads rows qui ne peuvent pas être supprimés.
Quelles pistes devrions nous suivre?
Bonjour,
L'analyse d'un VACUUM sur une table d'une de nos bases nous indique le message suivant "DETAIL: 193074 dead row versions cannot be removed yet."
Quel est la signification de ce message, quelles en sont les conséquences et bien sur, comment y remédier?
En vous remerciant par avance de vos informations et réponses.
ps: Le résultat complet du vacuum verbose analyse:
INFO: vacuuming "public.fcommer"
INFO: index "fcommer_ix" now contains 240965 row versions in 1555 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.01s/0.00u sec elapsed 0.71 sec.
INFO: index "i_co_id" now contains 240965 row versions in 1042 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.38 sec.
INFO: index "i_co_id2" now contains 240965 row versions in 1560 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.01s/0.00u sec elapsed 0.40 sec.
INFO: index "i_cosiret" now contains 240965 row versions in 1380 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.39 sec.
INFO: index "i_cosite" now contains 240965 row versions in 1049 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.31 sec.
INFO: index "i_coenseigne" now contains 240965 row versions in 1375 pages
DETAIL: 0 index row versions were removed.
17 index pages have been deleted, 0 are currently reusable.
CPU 0.01s/0.00u sec elapsed 0.56 sec.
INFO: "fcommer": found 0 removable, 240965 nonremovable row versions in 7154 pages
DETAIL: 193074 dead row versions cannot be removed yet.
There were 268 unused item pointers.
1 pages contain useful free space.
0 pages are entirely empty.
CPU 0.13s/0.04u sec elapsed 4.78 sec.
INFO: analyzing "public.fcommer"
INFO: "fcommer": scanned 3000 of 7154 pages, containing 20804 live rows and 80252 dead rows; 3000 rows in sample, 49611 estimated total rows
Pages : 1
