Vous n'êtes pas identifié(e).
J'ai besoin d'un champs unique avec la concaténation de deux champs existants
Si le but est de maintenir une contrainte:
CREATE UNIQUE INDEX ON nom_table ( (champs1 || champs2) );
Pas besoin de matérialiser dans la table....
pas parfait, ce serait plus agréable avec 0001-01-00 comme date de départ ( mais ce n'est pas une date valide):
# prepare dow (int) as select to_char('0001-01-07'::date + $1,'Day');
# execute dow(1);- Est-il possible de paramétrer postgresql.conf afin d'avoir un fichier de log par base ?
Non, mais vu vos questions, je pense que pgaudit devrait vous intéresser (log par base de données entre autre).
https://github.com/2ndQuadrant/pgaudit
Ce que je souhaite faire c'est un alter table pour modifier mes colonnes de type "real" en "double precision" et savoir quels seraient les éventuels impacts.
En effet, ça me simplifierais la tâche pour la modification de mes procédures de n'avoir à gérer que les types "bigint" et "double precision"...
Merci
L'impact est principalement applicatif, la précision change.
# select 1.12345::real = 1.12345::double precision;
renvoie false.Donc en appliquant des conversions vous allez potentiellement obtenir des égalités là où il ne devrait pas y en avoir. On n'utilise habituellement pas ces types de données pour ce genre d'opération ceci dit.
Si l'applicatif est compatible avec ce changement, en effet, coté PostgreSQL, l'impact est sur le volume de stockage, modulo ce qui suit.
Attention aussi aux fonctions d’agrégation statistique qui vont être affectées par le format de stockage initial (avg, variance, stddev, ...):
# create table foo
as select ('1.'||n)::real as s,('1.'||n)::double precision as d from generate_series(1,99999) g(n);
# select avg(s),avg(d) from foo;
avg | avg
------------------------+----------------
1.54997749977667 | 1.549977499775
# alter table foo alter COLUMN s type double precision;
# select avg(s),avg(d) from foo;
avg | avg
------------------+----------------
1.54997749977667 | 1.549977499775NOTE: les fonctions de stats retournent "double precision" dans tous les cas de paramètres flottant en entrée, on note que le résultat est différent ci-dessus alors que:
# truncate table foo;
# insert into foo select ('1.'||n)::double precision as s,('1.'||n)::double precision as d from generate_series(1,99999) g(n);
# select avg(s),avg(d) from foo;
avg | avg
----------------+----------------
1.549977499775 | 1.549977499775Donc peut-être auriez-vous intérêt à caster lors de l'import initial, et pas dans un second temps.
Malheureusement, mon nom de champ est traduit par une variable var_champ inclue dans une boucle.
Quand je fais simplement
NEW.var_champ=var_valeur;Postgres me répond
record "new" has no field "var_champ"et n'interpréte la variable en tant que variable.
On peux probablement faire une fonction sefiled() pour gérer ca. Toutefois, il y a peut etre mieux à faire dans la fonction pour ne pas avoir besoin de faire une fonction setfield() !
Quel est le code de la fonction trigger actuelle ?
Il est possible de procéder à des optimisations d'une partie des requêtes, en particulier en conjonction avec du partitionnement, en utilisant pg_export_snapshot(), l'intelligence d'utilisation des ressources n'est pas fournie par PostgreSQL ceci dit.
Il faut utiliser l'outil pg_controldata par exemple, qui permet de savoir quel est le statut actuel d'un serveur.
Si on peut se connecter sur le serveur il est possible d'utiliser: pg_is_in_recovery()
Bonjour,
Je travaille avec une 9.0 sur CentOS 5.
Suite à des problèmes de connexions (too many clients already) et à des fichiers de Log inexploitable (2 Go, tout est tracé, un fichier par jour, avec rotation du 01 au 31), je retravaille la stratégie de tracage, en prenant en compte le fait de pouvoir exploiter les fichiers avec PGFOUINE.
J'ai paramétré mon postgresql.conf avec :
log_destination = 'csvlog'
logging_collector = on
log_directory = '/home/postgres/PG_LOG'
log_filename = '%u-%H'
log_truncate_on_rotation = on
log_rotation_age = 1h
log_min_duration_statement = 0
log_connections = on
log_disconnections = on
log_line_prefix = '%t [%p]: [%l-1] ' # préconisé pour PGFOUINE
lc_messages = 'en_US.UTF8' # préconisé pour PGFOUINEJ'obtiens maintenant 2 fichiers par heure, par exemple :
-rw------- 1 postgres postgres 0 fév 6 10:00 1-10
-rw------- 1 postgres postgres 0 fév 6 10:00 1-10.csv
-rw------- 1 postgres postgres 0 fév 6 11:00 1-11
-rw------- 1 postgres postgres 0 fév 6 11:00 1-11.csvPour quelle raison, je ne trouve pas ?
J'ai vu que pour PGFOUINE, il fallait modifier le fichier CsvlogLogReader.class.php pour gérer une version 9. J'ai donc remplacé la ligne indiqué (if((count($csvLine) == 22) || (count($csvLine) == 23)) {).
J'exécute la commande : pgfouine.php -file /home/postgres/PG_LOG/1-11.csv -format text -logtype csvlog > pierre.txt
et je reçois :
pgFouine did not find any valid PostgreSQL log line in your log file:
* check that PostgreSQL uses an english locale for logging (lc_messages in your postgresql.conf),
* check that you use the -logtype option (syslog, stderr) according to your log file,
* if you use syslog and log_line_prefix, check that your log_line_prefix has a trailing space,
* if you use stderr, check that your log_line_prefix is of the form '%t [%p]: [%l-1] '.
If you think your log file and your options are correct, please contact the author (gsmet on #postgresql@freenode or guillaume-pg at smet dot org).Quelqu'un peut-il m'aider ?
étrange, les fichier sont manifestement vides.
Pouvez-vous vérifier les paramètres en cours avec la requete suivante:
select name,setting,context,source from pg_settings where source != 'default' order by 1;
@dverite:
déjà tenté: une definition du caractere de separation par la manip ALT+code affiche le message d'erreur
"ERREUR: le délimiteur COPY doit être sur un seul caractère sur un octet" (et ceci pour 161 ou 173)@Marc Cousin
dans les deux autres cas, soit pg me repond
"ERREUR: séquence d'octets invalide pour l'encodage « UTF8 » : 0xad" ou
"ERREUR: le délimiteur COPY doit être sur un seul caractère sur un octet"si j'essaie de creuser en codant le separateur en utf8 j'obtiens soit du "sequence d'octets invalide", soit un rappel que le séparateur doit être codé sur un caractère :-(
dommage. Comme je n'ai aucun levier sur le choix du separateur, je suis donc obligé de faire le pré-traitement du csv.
merci quand meme pour votre aide.
cdt
Par défaut le lecteur de csv fournit via multicorn n'accepte pas ce caractère spécial, mais je suppose qu'il est possible de le modifier en ce sens.
http://multicorn.org/foreign-data-wrapp … ta-wrapper
il est toujours possible de se baser sur sur un système de réplication comme slony pour migrer entre versions, dans les deux sens.
très sincèrement, je vous conseille de considérer de passer du temps sur la mise à jour de PostgreSQL, ce qui est sûrement l'opération la plus rentable que vous pourrez faire.
Se tourner du coté de l'ERP et lui consacrer une mise à jour me semble tout aussi pertinent (quel ERP est-ce donc ?)
Oui, effectivement. Mais à partir de ce moment là, ça veut dire qu'on fait un COPY vers un fichier, donc faut être super utilisateur. Donc avoir un trigger security definer avec quelque chose qui écrit dans un fichier dedans. C'est pour cela qu'on avait jeté un voile pudique sur le sujet, je pense
certe ... j'ai pas lu tout le thread.
mais on peut lire, liste et éditer des fichiers en SQL ou PL/pgsql. En ajoutant un security definer, pas besoin d'etre superuser pour accéder à tel ou tel fichier.
Je m'en sers pour faire des démos de comment il est dangereux de laisser une appli etre superuser (au lieu d'utiliser security definer, et de controler I/O)
Bonjour,
Nous recherchons d'urgence un DBA pour des tests de perf, test de stress sur POSTGRESQL en forte volumétrie en concurrence d'ORACLE.
Cette mission est cadrée par des architectes intégrateurs et le résultat des tests orientera / impactera: la confection des socles techniques basés sur PostgreSQL et la documentation à l'usage des DBA de production.
La seconde partie de la mission consistera à maintenir le support niveau 3 des équipes de production.
Bonjour,
nous offrons ce genre de service chez 2ndQuadrant.
Vous pouvez me contacter directement à l'adresse ci-dessous.
Pas avec PL/pgsql en tout cas. Mais avec PL/perl ou PL/python, oui, bien sûr. Vous avez accès à toutes les bibliothèques Perl/Python dans ce cas là. De même avec une fonction en C.
en SQL, on peut utiliser COPY TO pour écrire dans un fichier, donc via un trigger si on veut vraiment.
@frost: YES, j'ai recréé la même Fn mais en utilisant VARCHAR au lieu de TEXT:
!
vous pouvez rester sur du TEXT, mais il faut utiliser la classe d'opérateur correspondant: text_pattern_ops
cf http://www.postgresql.org/docs/8.1/stat … class.html
Merci beaucoup pour vos éclaircissements.
Bonne soirée à vous!Miguel
notez que repmgr permet de trouver le meilleur node pour une bascule de failover (c'est à dire trouver le serveur qui a le moins de 'lag' avec le master) et que c'est grandement utile pour fiabiliser les bascules, d'autant plus en mode automatique.
http://repmgr.org/
Vous pouvez aussi voir les slides de repmgr lors du CHAR(11) (la conférence spécialisée dans le Clustering, Haute-Dispo, et Réplication)
http://www.2ndquadrant.com/static/2quad … char11.pdf
Depuis, pgbouncer a évolué et permet de mettre en place une architecture très simple à administrer à l'aide de serveurs DNS. (et rend obselete les serveurs type LVS)
Bonjour,
je suis a la recherche d'un outil (graphique si possible) permettant de voir en temps réel les requêtes en cours avec leurs impacts sur les perfs (I/O, CPU)Les requêtes en cours se trouvent facilement grâce au pg_stat_activity
Mais comment faire le lien entre un process et des infos du style : pg_statio_all_tables
Y a t-il des options à activer pour avoir un peu plus d'infos sur une requête ?
Existe t-il des outils déja tout fait ?Merci
Bonjour,
vous pouvez utiliser des outils comme 'ptop': http://ptop.projects.postgresql.org/
Pour ce qui est des IO, cpu, regardez les vues/fonctions fournit par pg_proctab. Cela correspond à ce qui est dans /proc/<PID>/
Vous n'aurez rien strictement lié à une requête actuellement, mais ce n'est pas impossible à développer.
Quand au coté graphique... tout ici est en mode 'console' mais il est aussi possible d'utiliser des logiciels externes pour grapher les informations.
Ok je verrais tout cela lundi. La requete a ete revu aussi et a permis de gagner un peu de temps mais j ai un gros souci c est que j aimerais bien comprendre pourquoi la meme requete prend un temps completemet different alors que mon pc est cense etre moins rapide que la prod en plus, je verifierai les schemas au cas ou mais il s agissait d un dump puis restore.
Je vous tiens au courant des que j ai pu tester tout cela.
Merci
un dump& restore ne reproduit pas les éventuels espaces morts que vous avez en prod. Cela change donc les estimations d'occupations de lignes vivantes par page.
Avez-vous des volumes similaires? (comparaison rapide à la mano : dans psql, \dt+ et \di+ pour connaitre les tables avec leur volumes disque)
Bonjour, le Pb a été fixe
la table pg_stat_activity lors du drop constraint precise que la transaction est en waiting = true
Après investigation , la table était locké par une transaction qui avait échoué lors d'un two-phase commit
Je vous conseille très fortement de contrôler le 2PC: cela impacte les taches de maintenance et peut introduire beaucoup (trop) d'espace mort dans vos tables et index.
Il y a eu plusieurs améliorations en 8.4.8 et 8.4.9 sur la gestion des joins/anti-join, bitmap, etc...
1/ Pour comparez vous devez utiliser la meme version en dev et en prod. (une mise à jour de la prod est souhaitable dans tous les cas)
2/ Il est possible que la qualité des échantillons statistiques diverge entre le dev et la prod, et que le plan soit lamentable en prod en raison de ce point.
2/ est facile à vérifier (procédez a un analyze des tables mise en oeuvre), et 1/ me semble la vraie cause de votre différence de performance entre les deux (car il implique la construction d'une mauvaise optimisation)
Merci de l'information, mais les requêtes SQL récursives ne peuvent résoudre à elle seules les questions qui sont traitées, car le module openbarter produit un premier graphe à partir de la base, puis un autre à partir du premier, puis encore un autre pour obtenir les résultats. A chaque phase, il y a un algorithme différent: le premier est depth-first, le deuxième est aussi depth-first, et le troisième une version adaptée de bellman-ford.
Il serais dans doute faisable de coder le tout en plgsql, mais avec les performances d'un langage interprété, et les problèmes de verouillages cycliques propres à la base. La stratégie que j'ai choisi consiste à extraire de la base les données d'entrée (un gros volume), les traiter en mémoire vive indépendamment des mécanismes de la base, et de soumettre les résultats à la base (très faible volume) en vérifiant que ces données ne sont pas obsolètes.A+
Bonjour,
très intéressant.
Pour le partie publication/communication, je vous suggère d'en faire une extension utilisable avec CREATE EXTENSION (9.1), puis de la publier sur PGXN. Vous pouvez l'annoncer sur la mailling list pgsql-announce, David Fetter se charge de la news hebdomadaire et vous pouvez aussi lui envoyer un mail en direct (cf archive postgresql pour avoir son mail). Vous pouvez aussi faire une annonce sur la mailling pgsql-fr-generale. (cf postgresql.org pour consulter/ss'abonner)
Utiliser le moteur PostgreSQL ne veut pas dire recoder votre extension en plpgsql, le C est très bien. La question qui demeure est qu'est-ce que berkely DB apporte que n'apporte pas déjà postgresql dans votre contexte. Je n'ai pas lu votre code mais je suppose qu'il suffit de changer le 'backend' berkeleyDB par postgresql, et voilà, non ?
bonjour,
je n'ai pas lu tout le fil de discussion. Toutefois, en réponse à l'article:
Construire toute un logique de mise à jour de la valeur d'une séquence me semble complètement inutile et montre le problème de normalisation du schéma SQL prévu.
Si le but est de changer le tri des données, on utilise une colonne spécifique.
Bonjour, je me permets de relancer ce topic pour avoir votre avis.
Nous avons en effet fait développé la "synchronisation" entre la la base "Prestataire" et la base "Mère" par une société de services. La base "Prestataire" se compose d'une quinzaine de tables et fait environ 2 Go. La synchronistaion adapte les données du prestataire à notre format de base de données et alimente ensuite notre base "Mère".
Le problème est qu'après 15 jours d'exécution, la synchro n'est toujours pas terminée. La société de services se justifie en distant que le nombre de données à synchroniser est "trop important" et que nous devrions prendre moins de données chez le prestataire pour optimiser les performances.
- Que pensez vous de cette justification?
- Avez vous déja développée une interface de synchronisation ressemblant à cela, et combien de temps vous a t'il fallu pour synchroniser 2 Go?Merci,
Je n'ai pas repris l'historique du fil, mais synchroniser 2 GO n'est pas censé prendre des jours, en fonction du process de transformation des données cela impacte mais bon, 2Giga c'est pas la mort. cela devrait prendre quelques heures. (encore une fois cela dépend du contexte et il est possible que la durée soit justifiée, dur a dire)
15 jours pour la synchro de 2GB, il y a tres probablement un soucis.
pg_dump est un outil se lance en ligne de commande, pas dans la console psql.
Il faut donc ouvrir un terminal et procéder de même mais sans 'psql maBD' (pg_dump maDB -f mon_fichier)
