QgisCadastrePlugin
QgisCadastrePlugin copied to clipboard
3liz
Ajouter une gestion d'exceptions lors de l'import SQL
Je suis sur un cas un peu particulier ou j'essaie d'importer un département entier (l'allier) avec mes scripts d'import extraitsdu plugin cadastre - ca marche bien dans certains cas, et dans d'autres la connection avec le serveur est coupée (pour une raison que je n'explique pas encore) lors de l'import majic. seul probleme, le code d'import ne gère pas correctement cette coupure, et continue allègrement, alors que la connection n'est plus la...
Symptome coté client:
. Import des fichiers majic
. /home/landry/datas/majic/2015/43/ART.DC21.W15430.BATI.N000896
/home/landry/datas/majic/2015/43/430.txt
/home/landry/datas/majic/2015/43/ART.DC21.W15430.LLOC.N000896
/home/landry/datas/majic/2015/43/ART.DC21.W15430.NBAT.N000896
connection already closed
connection already closed
connection already closed
connection already closed
coté serveur, le message est:
2015-08-26 16:01:03 CEST [24957-102] qadastre@qadastre LOG: could not send data to client: Broken pipe
2015-08-26 16:01:03 CEST [24957-103] qadastre@qadastre STATEMENT: BEGIN;SET search_path = "qad2015", public, pg_catalog;INSERT INTO "nbat"
VALUES ('430080 .....
A mon avis, il manque un try/finally/catch autour de la 2e boucle dans importMajicIntoDatabase, celle créant les batches de maxInsertRows lignes - si un batch d'INSERT echoue, le prochain sera quand meme tenté, sans message d'erreur/arrêt.
Pour revenir a la source du problème, l'import échoue toujours sur la table NBAT (lors de l'import du fichier brut, avant la mise en forme), pour l'allier ca echoue toujours apres ~1450000 enregistrements, pour la haute loire apres ~1300000 . J'ai essayé de diminuer maxInsertRows (pour l'instant je suis avec 100000), ca déplace/affine un peu le probleme mais ca finit toujours par échouer. Je me demande s'il n'ya pas une limite de taille cachée qqpart.....
C'est avec psql 9.4.3 sur debian jessie 64 bits, pareil avec psql 9.4.4 depuis le repository pgdg. Etrangement, sur une autre instance psql 9.4.4 (répartie/répliquée) j'ai pas eu le meme souci du tout et tout le département de l'allier a bien été importé en ~2h40.
(au passage, tout ceci se fait à travers un tunnel ssh, mais ce n'est pas ca qui tue la connection...)
Pour reference.. sur l'allier, BATI contient ~1600000 lignes (et est bien INSERT), NBAT contient ~4100000 enregistrements, sur la haute-loire BATI contient ~1080000 enregistrements et NBAT ~7370000. Je ne sais pas si des tests ont été faits avec autant de données ?
avec maxInsertRows=1000, sur le fichier NBAT de la haute-loire j'echoue a 2134000 .. et avec 10000, j'echoue sur 2130000. Comme s'il y'avait une ligne dans chaque fichier NBAT qui lui plaisait pas... mais ce n'est pas une erreur d'insertion comme un pbm de taille de champ, c'est une coupure de cnx tcp/psql.
avec maxInsertRows=10, ca met beaucoup plus de temps, mais j'echoue a 1921010 enregistrements. peut-etre lié au nombre de sessions begin/commit.... je fais un autre test en local pour éluder le pbm avec le forwarding ssh.
en local, evidemment ca marche (enfin, ca va plus loin dans l'import..)... reste le pbm de gérer proprement une déconnection intempestive :)
Il faudrait regarder les logs PostGreSQL pour voir ce qui est dit de ce côté là. Ainsi on connaîtra l'erreur exacte (trop de connexions, sessions interrompue, etc.)
C'est bien ca le problème, dans le log du serveur que j'ai mis dans le premier commentaire, a part 'could not send data to client: Broken pipe' il n'y a rien d'autre. Mais maintenant que je sais que c'était le forwarding ssh le souci.... en local ca marche bien, j'en suis a 3 départements importés sur 4.. Par contre, il faut trouver un moyen de gérer correctement cette exception quand la cnx est coupée.
Pardon, j'avais manqué les 2 lignes du log serveur avec le "broken pipe". En effet, il faut ajouter de la gestion d'exceptions pour les requêtes INSERT