PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 Re : Optimisation » Comment optimiser/réaliser ce traitement ? » 16/10/2020 21:11:37

- Lorsque j’exécute sur une très faible volumétrie (quelques lignes), cela fonctionne très bien mais quand je passe sur une volumétrie plus importante (un moins de données), ça tourne des heures (je n'ai jamais réussi à arriver au bout même après plusieurs heures d'exécution).

C'est impossible de vous aider ainsi. Il faudrait déterminer ce qui est lent dans la fonction (en supposant qu'il n'y en a qu'une). Pour cela, soit vous utilisez un profiler, soit vous ajoutez des instructions style RAISE LOG pour savoir où il en est.

- Je n'ai aucune visibilité sur l'avancement de la fonction, c'est une sorte de boite noire. Est-ce qu'il y a des moyens d'avoir des informations sur l'avancement du traitement (nombre de lignes traitées, ...) ?

Hé bien, vu que la fonction est un code que vous avez écrit, seul vous pouvez ajouter un code à cette fonction pour avoir ces informations. Le plus simple, comme dit précédemment, serait d'ajouter des instructions RAISE LOG avec un message indiquant la progression.

- Les fonctions ne permettent pas de réaliser des commit intermédiaires. Je pensais qu'en effectuant une procédure appelant une fonction (deuxième test) cela me permettrait de faire des commits intermédiaires, mais non.

Vous ne pouvez pas faire de COMMIT intermédiaires dans une fonction, quelque soit la façon dont elle est appelée.

#2 Re : Installation » Problème de déplacement (et version?) du dossier data » 16/10/2020 21:06:21

Pour savoir quel est le problème, il faudrait regarder dans les logs du serveur et y trouver le message d'erreur qu'il enregistre quand il n'arrive pas à démarrer.

Pour connaître la version du répertoire de données, vous avec un fichier PG_VERSION à la racine de ce répertoire. Il vous indiquera la version.

#3 Re : Général » J'aimerais avoir un conseil pour mon code sql (posgresql) SVP ! » 15/10/2020 21:53:07

Petits conseils : 1. Indiquer votre version de PostgreSQL (ça peut fonctionner sur une version mais pas sur une autre). 2. Indiquer les messages d'erreur.

Bref, j'ai essayé votre code sur une version 13. La création du premier domaine échoue avec l'erreur :

ERROR:  column "d_type_production" does not exist

Il se trouve que ce nom est le nom du domaine. Donc je suppose que vous voulez tester la valeur de la colonne, et ce n'est pas comme ça qu'on fait. Donc on va lire la référence de la commande "CREATE DOMAIN" (https://docs.postgresql.fr/13/sql-createdomain.html ), on regarde les exemples, et on trouve comment faire smile

#4 Re : Publications » PostgreSQL Sera t-il mangé comme MySQL?! » 15/10/2020 21:47:02

Bon, déjà, PostgreSQL ne peut pas être acheté comme MySQL. MySQL a toujours été dirigé par une société, que ce soit Oracle, Sun ou longtemps avant MySQL AB. Oracle n'a pu acheter MySQL que parce que MySQL était la propriété d'une société. Ce n'est pas le cas de PostgreSQL.

Concernant les membres de la Core Team, on y voit toujours trois entreprises (EDB/2ndQ, Redpill Linpro et Crunchy Data). Certes, l'une d'elle est majoritaire (60%) et cela doit être corrigé rapidement. Le fait même qu'un membre de la Core Team et employé d'EDB en parle ne peut que donner espoir, y compris aux plus sceptiques, que le problème est en cours de résolution.

De plus, il faut se rappeler que la Core Team n'a pas de gros pouvoirs. Ils décident principalement des dates de sortie. Le reste, ce sont les développeurs et les utilisateurs qui le décident. Là où ça devient plus gênant, c'est si une majorité de développeurs se trouve dans une seule et même société. C'est malheureusement le cas avec le monstre qu'est devenu EDB/2ndQuadrant. Mais si on regarde au niveau des commiters, on se trouve avec un EDB ayant 20% (5 sur 30 en gros) de commiters, et pas forcément les plus gros commiters. Les 2 plus importants commiters (Tom Lane et Andres Freund) n'en font pas partie.

Bref, pas de quoi s'inquiéter, surtout avec un Bruce qui veille au grain.

#5 Re : Installation » Création d'une connexion PostGIS depuis Quantum GIS » 13/10/2020 15:34:28

À partir du même PC ? dans ce cas, il faut vérifier les paramètres de connexion de Lizmap.

#6 Re : Installation » Création d'une connexion PostGIS depuis Quantum GIS » 11/10/2020 18:42:22

Ce type d'erreur ne concerne pas du tout le fichier pg_hba.conf.

Le serveur sur lequel vous essayez de vous connecter doit écouter sur le port 5433 sur l'interface réseau 193.52.197.10. Donc le fichier postgresql.conf du serveur doit avoir soit la valeur 193.52.197.10 soit la valeur * sur le paramètre listen_addresses, et la valeur 5433 sur le paramètre port. Si ce n'est pas le cas, il faut corriger votre fichier postgresql.conf ou vos paramètres de connexion sur pgAdmin. Si c'est le cas, c'est que vous avez un équipement réseau ou un logiciel réseau qui vous bloque (mais donc rien qui concerne PostgreSQL).

#7 Re : Installation » Création d'une connexion PostGIS depuis Quantum GIS » 10/10/2020 08:43:39

Quel est le message d'erreur lors de la tentative de connexion ?

#9 Re : Sécurité » Variable d'environnement PGPASSFILE sur Windows » 25/09/2020 18:00:25

PGPASSFILE est le nom du fichier uniquement, pas le chemin qui amène à ce fichier. Il n'est pas possible d'indiquer un autre répertoire, par cette variable ou par une autre variable.

Le mieux (et le plus sûr/sécurisé) est de passer le mot de passe aux différentes personnes et qu'elles le collent dans leur fichier .pgpass/pgpass.conf.

#10 Re : pgAdmin4 » Actualiser la liste "navigateur" à gauche. » 25/09/2020 15:08:22

1. Non, il faut la mettre à jour manuellement.
2. Non, pgAdmin respecte la hiérarchie fournie par le catalogue PostgreSQL.

#11 Re : Java » génération de clé primaire avec Hibernate » 17/09/2020 22:31:56

Là, clairement, c'est une problématique plus Java/Hibernate que PostgreSQL même smile

#12 Re : Général » db2topg » 17/09/2020 11:08:31

Je crois que le site web officiel https://pgloader.io/ l'explique très bien. C'est un outil de chargement de données. Il peut fonctionner directement à partir de fichiers (CSV ou tabulé) ou de bases de données (MySQL, SQL Server, et SQLite). Dans le cas des bases de données, il peut aussi créer le schéma PostgreSQL identique au schéma de la base de données source. Pour DB2, aucun travail ne semble en cours pour le supporter officiellement mais il est possible d'exporter les données au format CSV et les envoyer dans PostgreSQL via pgloader (bien plus simplement et rapidement qu'avec un simple COPY). ET donc évidemment pas de récupération native d'un schéma DB2 dans PostgreSQL. Il faudra le faire manuellement.

#13 Re : Général » [inconnu]@[inconnu] LOG: paquet de démarrage incomplet » 14/09/2020 14:49:19

Le "paquet de démarrage" concerne une demande de connexion qui ne s'est pas terminée correctement. C'est généralement un outil réseau (par exemple un outil qui vérifie quel port est ouvert sur une machine) qui déclenche ce genre de messages. Rien d'inquiétant, sauf si vous avez un méchant hacker qui cherche une faille pour se connecter à votre serveur smile

#14 Re : Général » db2topg » 09/09/2020 15:24:37

- Quelqu'un l'a t'il déjà utilisé, et dans l'affirmative peut-il me donner son avis et son retour d'expérience

Non, mais Marc, qui l'a codé, l'a utilisé, a priori avec succès.

- db2topg dans son ensemble est-il encore d'actualité (je vois des posts vieux de 2 ans)

Aucune idée.

- Est-il maintenu

Non.

- Ou peut-on le télécharger (l'adresse https://github.com/dalibo/db2topg ne semble pas proposer le téléchargement)

Le bouton Code propose pourtant de cloner le dépôt git ou de le télécharger sous la forme d'un zip.

- Faut-il 'Perl' sur les serveurs source et cible

Il faut Perl sur le serveur qui exécute cet outil.

#15 Re : ODBC » données geom tronquées à 8192 caractères » 06/09/2020 17:01:26

PostgreSQL ne tronque jamais les données silencieusement. Donc je dirais que le problème vient soit du pilote ODBC soit de Filemaker.

#16 Re : Général » extraire ligne qui suit une valeur 0 dans une table. » 02/09/2020 16:48:44

Mon avis est que cela doit se faire au niveau du client. SQL ne permettra pas de réaliser ça.

#17 Re : Général » automatisation du vaccum chaque jour et un vaccumfull chaque dimanche » 24/08/2020 13:59:23

Planifier un VACUUM FULL est une mauvaise idée en soi. Normalement, il faut exécuter suffisamment de VACUUM pour ne pas avoir besoin de VACUUM FULL. Cela peut passer par un script spécifique ou par l'autovacuum. Mais il faut vraiment avoir une grosse justification pour planifier périodiquement un VACUUM FULL.

#18 Re : Général » Pg_toast error pendant pg_upgrade » 24/08/2020 13:57:29

C'est étonnant, et ça semble plutot mauvais. Mauvais comme une corruption.

#19 Re : Général » Locks "sous transactions" » 24/08/2020 13:53:43

Non, pas de moyen de réellement suivre ces sous-transactions, à moins de tracer toutes les requetes. Le plus important serait de savoir quel session bloque la session ayant un wait event à SubtransControlLock.

#20 Re : Général » Requête au résultat partiellement correct » 23/07/2020 16:38:33

Difficile de vous répondre sans avoir accès à un jeu de données, au résultat observé et à celui attendu.

Pour avoir un plan d'exécution, il vous suffit d'ajouter l'instruction EXPLAIN avant la requête. Ceci dit, ça ne vous servira à rien ici.

#21 Re : Général » Requête au résultat partiellement correct » 23/07/2020 13:32:37

Vous faites un LEFT JOIN, donc vous obtiendrez toutes les lignes de table1 qu'il y ait correspondance avec table2 ou pas. Quand il n'y a pas correspondance avec table2, les colonnes de résultat pour table2 ont la valeur NULL. A priori, vous voulez plutôt faire un JOIN qu'un LEFT JOIN.

#22 Re : Général » Trigger SUM/ GROUP BY postgresql » 20/07/2020 14:19:57

Ce n'est pas si simple parce que vous allez avoir rapidement un problème de récursion. Si vous aveez un trigger sur UPDATE qui fait lui même un UPDATE de la même table, ça va de nouveau déclencher le trigger, qui va de nouveau faire un UPDATE qui va lui-même déclencher encore le trigger. Et ça continuera indéfinimment. Plus exactement, ça continuera jusqu'à avoir rempli la pile d'éxécution. Le problème vient surtout du fait que vos données ne sont pas correctement normalisées. Vous devriez avoir une table pour le site (avec nom du site et surface totale) et une table pour les éléments (avec la surface de chaque élément).

Sans changer la strtucture de la base, il va falloir vérifier le retour de la fonction pg_trigger_depth() pour s'assurer qu'il s'agit du premier appel du trigger, et faire un UPDATE du style "UPDATE table SET surface_to = (SELECT SUM(...) FROM table WHERE site=NEW.site) WHERE site=NEW.site" (syntaxe à revoir mais l'idée est là.

#23 Re : Général » Trigger SUM/ GROUP BY postgresql » 20/07/2020 13:34:13

Ce qui est logique. Avec un "NEW.colonne :=", vous essayez d'affecter une valeur à une colonne d'une ligne supprimée. Je pense que le mieux serait de fournir un exemple complet avec quelques lignes de la table pour qu'on comprenne mieux ce que vous voulez faire.

#24 Re : Général » Trigger SUM/ GROUP BY postgresql » 20/07/2020 12:25:53

L'erreur de la colonne est due au fait que vous ne l'avez pas préfixé du nom de la table (NEW) alors que vous l'avez bien fait pour surface_total et geom.

Il me semble toujours qu'il faudrait changer la requête (et notamment abandonner le GROUP BY site) mais je ne sais pas exactement par quoi actuellement.

#25 Re : Général » Trigger SUM/ GROUP BY postgresql » 20/07/2020 11:55:28

Généralement, les problèmes de nom proviennent de l'ajout de majuscules dans le nom problématique, auquel cas, il faut placer le nom entre colonne.

Ceci étant, la requête n'a pas de sens pour moi. Quand un fait un GROUP BY sur un SUM, on s'attend à récupérer plusieurs lignes. Or, vous affectez le résultat du SUMM à une colonne. Comment une colonne pourrait enresgitrer plusieurs valeurs pour la même ligne (celle en cours de mise à jour) ?

Pied de page des forums

Propulsé par FluxBB