Plantage lors de l'import dès que le schéma devient trop volumineux

[equinton]

Après avoir importé plusieurs centaines (ou milliers) de fichiers, le programme d'importation plante systématiquement à cette étape : ERROR: current transaction is aborted, commands ignored until end of transaction block 2018-05-03 09:21:59 CEST [8704-18] quinton@cadastre STATEMENT: SET search_path = "cadastre", public, pg_catalog;DROP TABLE IF EXISTS "batiment_id";DROP TABLE IF EXISTS "borne_id";DROP TABLE IF EXISTS "boulon_id";DROP TABLE IF EXISTS "commune_id";DROP TABLE IF EXISTS "croix_id";DROP TABLE IF EXISTS "id_s_obj_z_1_2_2";DROP TABLE IF EXISTS "lieudit_id";DROP TABLE IF EXISTS "numvoie_id";DROP TABLE IF EXISTS "parcelle_id";DROP TABLE IF EXISTS "ptcanv_id";DROP TABLE IF EXISTS "section_id";DROP TABLE IF EXISTS "subdfisc_id";DROP TABLE IF EXISTS "subdsect_id";DROP TABLE IF EXISTS "symblim_id";DROP TABLE IF EXISTS "tline_id";DROP TABLE IF EXISTS "tpoint_id";DROP TABLE IF EXISTS "tronfluv_id";DROP TABLE IF EXISTS "tronroute_id";DROP TABLE IF EXISTS "tsurf_id";DROP TABLE IF EXISTS "voiep_id";DROP TABLE IF EXISTS "zoncommuni_id";

Si je lance l'importation dans un nouveau schéma, pas de problème (pour le même lot de fichiers).

Il semble toutefois que l'importation est réalisée, le nombre de lignes dans v_geo_parcelle ayant augmenté.

J'ai tenté d'augmenter la mémoire du serveur Postgresql 9.5, mais ça n'a rien donné : shared_buffers = 256MB temp_buffers = 16MB work_mem = 32MB maintenance_work_mem = 128MB max_locks_per_transaction = 128 max_pred_locks_per_transaction = 128

S'il s'agit de la dernière phase, ce n'est pas très grave.

Log du plugin : INITIALISATION

• Copie du répertoire /home/quinton/.qgis2/python/plugins/cadastre/scripts/plugin 0 s EDIGEO Type de base : postgis, Connexion: localhost-cadastre, Schéma: cadastre
• Décompression des fichiers 13 s Suppression des contraintes
• SUPPRESSION DES CONTRAINTES D'INTEGRITEES : DEBUT
• suppression clefs primaires
• SUPPRESSION DES CONTRAINTES D'INTEGRITEES : FIN 14 s Création des tables edigeo 14 s Suppression des indexes 14 s
• Import des fichiers EDIGEO dans la base
• Import des fichiers via ogr2ogr
• Import des relations (*.vec)
• 6 multipolygones mis à jours dans la base de données 343 s Mise en forme des données
• FORMATAGE DONNEES : DEBUT
• Suppression des données du lot '2017' 343 s
• index pour optimisation 345 s
• geo_commune: utilisation de max et non distinct on pour compatibilite sqlite 348 s
• geo_section 348 s
• geo_subdsect 349 s
• geo_parcelle 349 s
• Indexes sur geo_parcelle et geo_commune pour optimisation 353 s
• geo_subdfisc 359 s
• geo_subdfisc_parcelle 359 s
• geo_voiep 359 s
• geo_numvoie 359 s
• geo_numvoie_parcelle 359 s
• geo_lieudit 361 s
• geo_batiment 363 s
• geo_batiment_parcelle 363 s
• geo_zoncommuni 387 s
• geo_tronfluv 387 s
• geo_tronroute 387 s
• geo_sym 387 s
• geo_ptcanv 388 s
• geo_borne 388 s
• geo_borne_parcelle 388 s
• geo_croix 391 s
• geo_croix_parcelle 391 s
• geo_symblim 391 s
• geo_symblim_parcelle 391 s
• geo_tpoint 394 s
• geo_tpoint_commune 394 s
• geo_tline 394 s
• geo_tline_commune 394 s
• geo_tsurf 396 s
• geo_tsurf_commune 396 s
• suppression des index temporaires 396 s
• analyses 397 s
• FORMATAGE DONNEES : FIN 403 s Placement des étiquettes 404 s Création des indexes spatiaux
• attributes 442 s 461 s Ajout des contraintes
• CREATION DES CONTRAINTES D'INTEGRITEES : DEBUT
• création clé primaire
• création clé étrangère
• CREATION DES CONTRAINTES D'INTEGRITEES : FIN 466 s Ajout de la table parcelle_info 473 s current transaction is aborted, commands ignored until end of transaction block FINALISATION

Cordialement,

Eric Quinton

[MaelREBOUX]

Bonjour @equinton

Votre problème est-il toujours d'actualité ?

[equinton]

Bonjour,

Je n'ai pas retenté d'importation depuis 2018, je ne pourrai vous dire si le problème persiste ou non.

Cordialement,

[MaelREBOUX]

OK. Je préfère donc fermer ci ticket. Vous pourrez le rouvrir si nécessaire.