Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#326 Re : PL/Perl » Plantage process serveur lors de l'appel de unaccent » 28/08/2015 15:09:08
En-dehors de la rapidité, il y a la question du bon fonctionnement.
La question des ligatures n'est pas simple mais pour ma part je trouve que remplacer œil par eil n'a aucun sens, dans aucun contexte, et pourtant c'est ce que fait actuellement le unaccent() de contrib.
Il n'est pas dit qu'il fera toujours ça, il y a un patch en cours là-dessus qui transforme les ligatures en plusieurs lettres
https://commitfest.postgresql.org/6/301/
en rapport avec: BUG #13440: unaccent does not remove all diacritics
...et la discussion associée montre que le comportement attendu de cette fonction ne tombe pas sous le sens.
#327 Re : PL/Perl » Plantage process serveur lors de l'appel de unaccent » 26/08/2015 15:53:56
Une autre méthode envisageable serait d'utiliser Unicode::Normalize qui a l'avantage d'être un module de base dans Perl.
use Unicode::Normalize;
my $w=NFD($_[0]);
$w =~ s/\pM//g; # strip combining characters
return $w;A confirmer par vos propres tests, mais ça me semble aussi deux fois plus rapide que unac_string() de Text::Unaccent::PurePerl
#328 Re : PL/Perl » Plantage process serveur lors de l'appel de unaccent » 25/08/2015 15:38:22
Pour la version pure perl, le tableau associatif prend plus de 17000 lignes de code.
Il faudrait le sortir de la fonction pour avoir un temps acceptable, sinon le CPU doit passer son temps à réaffecter cette table géante à chaque fois.
Via "use Text::Unaccent::PurePerl" (plperlU) il serait initialisé une seule fois.
Pour rester en plperl (trusted), j'imagine qu'il faudrait le mettre dans $_SHARED dans une étape à part appelée une seule fois.
#329 Re : Général » requete crosstab » 24/08/2015 16:37:11
Malheureusement, il faut obligatoirement 3 étapes avec crosstab lorsque la liste des colonnes est variable.
- 1: récupérer la liste des colonnes via une requête SQL, du style
select distinct nature from voirie;- 2: injecter cette liste dans une requête SQL crosstab à 2 paramètres, plus une déclaration de type de retour
Cette requête va ressembler à ce modèle (que je reprends de la question, je ne sais pas si elle est juste)
SELECT *
FROM crosstab('
SELECT INSEE,nature,sum(longeur_ml)
FROM voirie
group by INSEE,nature
order by nature',
'SELECT nature
FROM voirie
group by nature
order by nature')
AS ct
(
"enrobé" numeric(10,2),
"bicouche" numeric(10,2),
"graviers" numeric(10,2),
"sablé" numeric(10,2)
.... etc ...
)(encore que généralement on trie par la 1ere colonne qui serait ici INSEE, et non la 2eme, à vérifier).
- 3: exécuter cette requête.
Il n'est pas possible d'encapsuler ces étapes en une seule fonction sur le serveur, sinon crosstab le ferait.
En ce qui concerne le plantage de postgresql, ce n'est biensûr pas normal, même s'il y a beaucoup de colonnes.
Ca pourrait donner lieu à un rapport de bug surtout si c'est reproductible, et si les versions de postgres et crosstab sont à jour et bien identifiées.
Une autre option est de pivoter le résultat côté client au lieu de le faire côté serveur. Mais il faut écrire un bout de programme client.
#330 Re : PL/Perl » Plantage process serveur lors de l'appel de unaccent » 24/08/2015 15:11:26
Text::Unaccent a un méchant bug d'écrasement de données dans la pile qui se produit en 64 bits. C'est dû à une confusion entre size_t (8 octets) et int (4 octets) qui d'ailleurs est signalée à la compilation.
Le problème a été vu dès 2006
https://rt.cpan.org/Public/Bug/Display.html?id=21177
mais l'auteur de Text::Unaccent avait apparemment déjà abandonné son package et ce rapport de bugs (et d'autres d'ailleurs) sont restés lettre morte.
Au vu de la backtrace, je pense que c'est que ça qui plante et que ça n'a rien à voir avec postgres ou plperl. Il se peut qu'avec la debian d'avant ça passait à travers le bug mais il y a un caractère aléatoire, tout dépend de ce qui se trouve en pile à cet endroit là. S'il y a une variable qui ne sert plus, ça passe. S'il y a un pointeur passé à free(), ça segfault. Or le compilateur met les variables en pile dans l'ordre qu'il veut.
Idéalement sur CPAN il faudrait qu'un autre mainteneur prenne la main et applique les patches, mais je ne crois pas que CPAN ait une politique de récupération des modules à l'abandon. Peut-être qu'au niveau de Debian?
Tu peux régler le problème au niveau de ton installation en compilant toi-même, ou sinon utiliser autre chose. Vu comment est fait Unaccent, je soupçonne que des puristes d'Unicode diraient que c'est n'importe quoi de toute manière.
#331 Re : Général » suivre en temps réel mon serveur postgresql » 11/08/2015 14:50:35
ptop est dispo en package sur ubuntu, mais a été renommé puisque ce nom est en conflit avec d'autres usages.
Ca s'installe avec apt-get install pgtop
et ensuite le binaire à appeler s'appelle pg_top
#332 Re : Général » fonction de mise à jour automatique (trigger) » 03/08/2015 18:57:19
Je suis perdu avec tout ce qui se dit sur le net concernant les fonctions "trigger" et leur utilisation.
Oubliez les triggers si vous êtes débutant.
La confusion consiste à partir du principe qu'un trigger serait nécessaire pour faire des opérations basiques.
Ne faites ni fonction ni trigger.
Il y a besoin de créer une nouvelle ligne? Faites un INSERT.
Il y a besoin de mettre à jour une ligne existante? Faites un UPDATE.
Un seul UPDATE permet de mettre à jour plusieurs colonnes de la même ligne.
#333 Re : Optimisation » accès lent sur serveur non localhost » 08/07/2015 14:28:44
Transférer des données d'un serveur à lui-même, c'est plus rapide que d'un serveur à l'autre via une vraie connexion réseau.
C'est normal et ces résultats n'ont pas l'air de dire autre chose.
Et si la connexion entre les deux serveurs est en SSL, ça fait aussi une grande différence.
#334 Re : Général » Fonction replace() avec des données BYTEA » 25/06/2015 13:13:40
J'ai une fonction (plpgsql) qui fait ça, je l'ai mis sur le wiki:
#335 Re : Général » plantage postgres » 25/06/2015 12:32:34
Je pensais récupérer les fichiers du répertoire base et les mettre sur un autres serveurs.
Est ce que cela fonctionnera ?
Non il faut le répertoire un niveau au-dessus, le répertoire data.
#336 Re : Sécurité » changement d'utilisateur courant dans la suppression en cascade » 12/05/2015 16:54:01
Pour logger le nom d'utilisateur dans le trigger sur la table secondaire, il faudrait utiliser session_user plutôt que current_user.
Pour le problème du droit d'effaçement, il y a une contradiction entre la déclaration "ON DELETE CASCADE" d'une table à l'autre et le fait qu'un utilisateur n'ait le droit de DELETE que d'un côté de la relation.
Postgres résoud implicitement le problème en faisant systématiquement le DELETE dans l'autre table avec les droits du possesseur, prenant d'une certaine manière le parti que la déclaration "ON DELETE CASCADE" est prioritaire par rapport aux GRANT sur l'autre table.
Si une application estime le contraire, elle ne doit pas utiliser "ON DELETE CASCADE" et gérer elle-même l'intégrité référentielle dans les suppressions.
#337 Re : Général » Trigger vers Node.js » 04/05/2015 15:27:09
Il faut créer le trigger sur ce modèle
CREATE TRIGGER nomdutrigger
AFTER UPDATE OR INSERT
ON nomdelatable
FOR EACH ROW
EXECUTE PROCEDURE fonction_liee_au_trigger();( à adapter)
La fonction proposée plus haut est aussi juste un modèle. S'il s'agit de conditionner le notify a un changement de valeur, un test de ce style fera l'affaire dans la fonction triggger en plpgsql (sinon depuis quelques versions de PG il est aussi possible de faire des conditions WHEN sur les colonnes dès la définition du trigger, voir la doc):
IF (NEW.nomcolonne IS DISTINCT FROM OLD.nomcolonne) THEN
perform pg_notify(etc..)
END IF;L'avantage de IS DISTINCT FROM est qu'il gère bien les transition de ou vers NULL s'il s'avère que la colonne peut être à NULL.
#338 Re : Général » Trigger vers Node.js » 04/05/2015 15:05:34
Avec un LISTEN actif dans un terminal psql est-ce que ça reçoit la notification ou pas?
Le client en ligne de commande psql affiche les notifications avec des messages du style
Notification asynchrone « nom_evenement » reçue avec le contenu « truc » en provenance du
processus serveur de PID numéro.
Les notifications n'arrivent qu'après (et si) la transaction est COMMITée.
#339 Re : Général » Trigger vers Node.js » 04/05/2015 14:56:25
Personnellement je regarderai vers une solution du style:
1) Côté envoi: trigger en plpgsql qui NOTIFY avec les données qui vont bien en paramètre
CREATE FUNCTION trigger_notify() RETURNS trigger AS
$$ BEGIN
perform pg_notify('nom_evenement', row_to_json(NEW)::text);
return new;
END
$$ language plpgsql;row_to_json() est dispo à partir de PG 9.2. On pourrait utiliser n'importe quoi d'autre qui transforme la ligne en texte mais JSON est le plus évident pour un récepteur en Javascript.
2) Côté réception avec Node.js mettre en oeuvre le LISTEN comme par exemple indiqué ici:
#340 Re : Général » import de fichier de données depuis un poste client » 16/04/2015 16:15:58
Access ne saura pas utiliser COPY via un driver ODBC quels que soient les arguments.
Mais comme un fichier CSV est attachable en tant que table à Access via un driver ODBC CSV, une requête INSERT fait l'affaire avec une table source en CSV attaché et une table cible PostgreSQL attachée via ODBC également.
#341 Re : PL/pgSQL » [RESOLU] Capturer une exception générée par un trigger » 01/04/2015 11:33:16
Le message d'erreur est dans la variable SQLERRM et il y a également un code dans SQLSTATE
exception
when others then
raise info '%: %', SQLSTATE, SQLERRM;#342 Re : Général » Héritage entre tables » 09/02/2015 15:35:48
J'ai fait l'erreur de charger en commençant par les tables filles
Ce n'est pas une erreur, c'est comme ça qu'il faut faire.
L'héritage dans PostgreSQL concerne la structure des tables uniquement. Le fait d'insérer dans une table fille ne propage pas les
données dans la table mère et l'inverse non plus.
Une erreur classique quand on débute avec l'héritage est de croire qu'on accède aux données de la table mère en faisant:
SELECT * FROM table_mere;
En réalité ce SELECT renvoie bien les lignes de la table mère s'il y en a, mais aussi celles de toutes les
tables filles pour la partie des colonnes héritant de la table mère.
Il faut faire:
SELECT * FROM ONLY table_mere;
pour avoir les lignes de la table parent sans celles des tables héritées. Dans le cas typique où cette table parente sert uniquement à définir une structure héritable, elle ne contiendra aucune ligne.
#343 Re : Général » Résultat d'une fonction » 10/12/2014 13:06:56
Cette fonction vous paraît-elle également absurde? Comment aurais-je dû procéder?
Je ne sais pas, c'est totalement différent de la version précédente puisque là chaque valeur t2/t3/etc.. dépend de la précédente avec une sorte de chaînage.
Dans la version d'avant, on a l'impression que horodate est une clef mais dans celle-là non et ça change tout.
#344 Re : Général » Résultat d'une fonction » 05/12/2014 19:16:08
Ma table de données doit faire 1000 à 2000 lignes, la fonction devrait donc retourner 1000 lignes par horodate et pas 20 non?
En soi la fonction ne renvoie aucune ligne, elle renvoie une valeur scalaire vu qu'elle est déclarée en RETURNS smallint.
Des fonctions qui renvoient des lignes, ça existe par ailleurs avec une déclaration du type RETURNS SETOF type mais ce n'est pas le sujet ici.
La requête SELECT en revanche, retourne des lignes, et en l'occurrence SELECT mafonction(x) FROM matable renvoie donc autant de lignes qu'il y en a dans matable, et la fonction est appelée autant de fois qu'il y a de lignes dans la table.
Pour une solution efficace, d'après la réponse précédente, le but est bien ce que je pensais et donc la fonction n'est pas utile, tout peut être aggrégé en une seule requête comme proposé plus haut, le SUM(CASE...) donnant bien le résultat attendu. Ce n'est pas juste une optimisation: dans la question initiale, la manière donc la fonction est combinée avec la requête pour calculer un aggrégat est réellement absurde en logique SQL.
#345 Re : Général » Résultat d'une fonction » 05/12/2014 12:58:32
L'objectif poursuivi semble être une aggrégation sur l'horodate, l'aggrégat étant le résultat de la fonction montrée.
Dans ce cas, ça ne peut pas marcher tel que montré, d'abord parce qu'une fonction aggrégat nécessite un CREATE AGGREGATE et un codage spécifique, ensuite parce que la requête doit avoir un GROUP BY.
Ce qu'il faut comprendre c'est que quand on fait "select fonction(x) from table" et que la table contient 20 lignes, on obtient 20 résultats. Peu importe que la fonction elle-même aille chercher d'autres lignes dans la même table et fasse des additions.
Le résultat voulu et qui est conforme à la logique SQL se rapproche peut-être de ça (ne nécessite pas fonction plpgsql):
select
horodate,
sum(
case when champ=x1 then t1*0.46
when champ=x2 then t2
... etc...
else 0 end
)
GROUP BY horodate;Ce qui resterait assez bizarre c'est ce que représentent ces x1, x2,... On s'attendrait à des constantes litérales (nom du champ dans une table Entité-valeur) alors que syntaxiquement ici c'est un nom de colonne.
#346 Re : Général » Service Postgresql ne démarre pas » 12/11/2014 14:54:23
2014-11-07 13:34:28 CET LOG: type de connexion «  » invalide
Au vu de ces caractères il s'agit d'un marqueur BOM indésirable. Le fichier a dû être modifié par un éditeur de texte qui l'a sauvé en ajoutant cet entête.
Il me semble que notamment notepad de Windows peut causer ce problème, il faut faire attention au format de fichier en sauvant.
Le principe du BOM est décrit dans wikipedia: http://fr.wikipedia.org/wiki/Indicateur … des_octets
qui d'ailleurs prédit même cette erreur :
Dans le cas d'un texte unicode-UTF-8 affiché avec un mauvais encodage (c'est-à-dire que l'encodage utilisé n'est pas celui qui devrait être utilisé), l'utilisateur est confronté en début de page/texte à une courte séquence de caractères incompréhensibles sans significations, en particulier avec l'encodage iso-8859-1, les trois caractères suivants apparaissent au début de texte : 
#347 Re : Installation » Sécurité PostgreSQL et petits réseaux ou mode stand-alone » 27/10/2014 21:11:48
ça n'arrivera surement jamais qu'un client connaisse la manip pour passer en mode trust
Sur google si on cherche "postgresql se logger sans mot de passe" on sait immédiatement comment faire. Comme l'oubli de mot de passe est un grand classique, ce type de manip est abondamment documenté, toujours avec la même réponse: mettre provisoirement trust.
Un admin neuneu qui ferait ça alors qu'il n'est pas censé le faire, c'est un scénario réaliste, on a vu pire. C'est pourquoi rendre ça inopérant a une utilité pratique même si c'est contournable, en réinstallant postgres ou autre. Certes avec un accès physique au serveur et a fortiori avec un compte admin on peut théoriquement faire ce qu'on veut, mais ça n'empêche pas de mitiger le risque en augmentant la difficulté.
#348 Re : Installation » Sécurité PostgreSQL et petits réseaux ou mode stand-alone » 26/10/2014 01:21:03
Si les binaires de PostgreSQL sont livrés avec l'application, il n'est pas compliqué de supprimer la fonctionnalité qui permet l'authentification "trust".
Il faut aller dans les sources, fichier src/backend/libpq/auth.c et dans la fonction ClientAuthentication(), forcer une sortie d'erreur sur le même modèle que les autre erreurs d'authentification. Par exemple:
case uaRADIUS:
status = CheckRADIUSAuth(port);
break;
case uaTrust:
ereport(FATAL,
(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
errmsg("trust authentication is not supported")));
/*status = STATUS_OK;*/
break;Dans le bout de code ci-dessus, l'appel de ereport(FATAL, ...) a été ajouté et ça doit suffire à inhiber ce mode d'authentification.
Ensuite la difficulté peut être de recompiler si on ne l'a jamais fait, mais pour un développeur c'est du domaine du possible.
#349 Re : Installation » Problème initdb post changement d'authentification postgres en md5 » 25/10/2014 21:43:55
Effectivement cette ligne:
local all postgres 127.0.0.1 md5
est erronée car local en colonne 1 implique que la colonne 4 doit être le mode d'authentification et non une adresse IP, qui n'a pas de sens pour les connexions locales.
D'où l'erreur méthode d'authentification « 127.0.0.1 » invalide dans les logs.
Il suffit d'enlever l'adresse IP et ça passera.
#350 Re : Général » Vacuum full réalisé ou pas ? » 04/10/2013 17:51:08
L'analyze lui s'exécute bien chaque semaine et sur toutes les tables, alors que certaines ne subissent aucune modification, pour quelle raison ?
Parce que ce n'est tout à fait les mêmes règles qui déclenchent l'auto-analyze par rapport à l'auto-vacuum.
En particulier, l'auto-analyze s'intéresse au nombre de nouvelles lignes insérés alors que l'auto-vacuum ne s'y intéresse pas.
Voir dans la doc http://doc.postgresql.fr/9.2/maintenance.html ces formules:
limite du vacuum = limite de base du vacuum + facteur d'échelle du vacuum * nombre de lignes
Le nbre de lignes est "le nombre de lignes obsolètes depuis le dernier VACUUM", ça veut dire résultant de DELETEs ou UPDATEs
Pour analyze le même genre de formule:
limite du analyze = limite de base du analyze + facteur d'échelle du analyze * nombre de lignes
sauf qu'ici le nbre de lignes est "le nombre de lignes insérées, mises à jour et supprimées depuis le dernier ANALYZE"
Conclusion: pour une table qui subit essentiellement des d'insertions , l'analyze se déclenchera en automatique mais pas le vacuum. Apparement c'est le cas de la table montrée dans la sortie de pg_stat_user_tables puisque l'autoanalyze_count est à 23.
Si les performances d'accès à cette table ne se dégradent pas particulièrement au cours de la semaine, il n'y a pas de raison de toucher à son paramétrage. Ca ne peut pas se faire "au fil des semaines" puisque la table est physiquement récréée toutes les semaines.
En revanche si le VACUUM FULL était abandonné, ça changerait complètement le contexte.