Vous n'êtes pas identifié(e).
Pages : 1
Je ne pense pas que cela soit que la volumétrie qui ai impacter sur la durée de la requete à ce point. actuellement je suis à 46M de logs pour 60M hier (apres-midi) (16h)
ce qui est certains c'est que l'analyse y est pour beaucoup, les requêtes simples (1filtre) sont beaucoup plus rapides, le problème c'est que quand je dis beaucoup plus rapide c'est -30s
ce qui n'est toujours pas suffisant pour l'utilisation qu'on souhaitent en faire.
j'avais commencer à spliter les données car je pensais que ce que j'aurais gagner en performance ne serrait pas suffisant (20/30% de gain)
Et l'avantage c'est que cela me permet en même temps de trier mes données.
Je vais me renseigner sur l'autovacuum, en tous cas merci pour ton aide.
Bonne journée
rsyslog=> ALTER TABLE systemevents ALTER fromhost SET STATISTICS 1000;
ALTER TABLE
rsyslog=> ANALYZE systemevents;
ANALYZE
rsyslog=> EXPLAIN ANALYZE SELECT * FROM systemevents WHERE fromhost = 'XXXX' ORDER BY id desc LIMIT 20 ;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=26482.21..26482.26 rows=20 width=952) (actual time=8417.810..8417.831 rows=20 loops=1)
-> Sort (cost=26482.21..26499.58 rows=6949 width=952) (actual time=8417.806..8417.813 rows=20 loops=1)
Sort Key: id
Sort Method: top-N heapsort Memory: 30kB
-> Index Scan using nomequipement on systemevents (cost=0.00..26297.30 rows=6949 width=952) (actual time=0.184..8412.708 rows=2686 loops=1)
Index Cond: ((fromhost)::text = 'XXXX'::text)
Total runtime: 8419.195 ms
(7 rows)Les résultat sont bien plus intéressant, une requêtes sur cette base est beaucoup plus rapide
maintenant une question de fonctionnalité à quel moment la commande ANALYSE est-elle lancé automatiquement ? si elle est lancé.
Même question pour le VACUUM, est-ce qu'il faut le lancer manuellement ou elle se lance automatiquement de temps en temps ?.
Dans tous les cas Merci beaucoup pour tous les debug.
Il semblerais que les requêtes soient beaucoup plus rapide, après je sais pas si c'est le changement du temps d'analyse des stats pour en améliorer l'effet (si j'ai bien compris) ou du au faite que j'ai grandement réduit la base (40% en moins).
Surement que les deux on du jouer.
Merci encore
Cordialement
Dragondark De Lonlindil
rsyslog=> EXPLAIN ANALYZE SELECT * FROM systemevents WHERE fromhost = 'XXXX' ORDER BY id desc LIMIT 20 ;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=0.00..26274.76 rows=20 width=957) (actual time=182283.090..238288.456 rows=20 loops=1)
-> Index Scan Backward using systemevents_pkey on systemevents (cost=0.00..85295739.77 rows=64926 width=957) (actual time=182283.086..238288.407 rows=20 loops=1)
Filter: ((fromhost)::text = 'XXXX'::text)
Total runtime: 238294.565 ms
(4 rows)
rsyslog=> SELECT count(*) FROM systemevents WHERE fromhost = 'XXXX';
count
-------
2750
(1 row)
rsyslog=>je viens de retest voir si j'avais pas fait une erreur mais non c'est bien le calcule qu'il fait.
si c'est bien ca que tu regardais.
une idée pour lui faire recalculer ces valeurs ?
Bonjour,
alors le premier résultat me liste une partie des équipements, en peu de temps
rsyslog=> SELECT * FROM pg_stats WHERE tablename='systemevents' and attname='fromhost';
schemaname | tablename | attname | null_frac | avg_width | n_distinct | most_common_vals | most_common_freqs | histogram_bounds | correlation
------------+--------------+----------+-----------+-----------+------------+-------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------+-------------
public | systemevents | fromhost | 0 | 12 | 217 | {liste 21 eqt) | {0.188233,0.175833,0.1531,0.0981667,0.0623,0.0125,0.0121,0.0111667,0.0110667,0.0106333,0.0105667,0.00946667,0.00826667,0.00823333,0.00773333,0.00723333,0.0068,0.0064,0.00603333,0.00603333,0.0059} | {liste 100 eqt) | 0.307883pour l'equipement, (il apparait pas dans la liste des équipements qui se trouvais dans la requete précédente
rsyslog=> SELECT count(*) FROM systemevents WHERE fromhost='XXXX';
count
-------
2838
(1 row)je dois être à peu prés vers les 80M d'enregistrement (ça stagne car je limite à 3mois d'enregistrement)
Et environ 600 équipements
'-'
rsyslog-> \d+ systemevents
ERROR: column "reltriggers" does not exist at character 41
LINE 1: SELECT relhasindex, relkind, relchecks, reltriggers, relhasr...Ma configuration actuellement :
# cat /evnt_log/postgresDB/postgresql.conf | grep ^[a-zA-Z0-9]
listen_addresses = '*'
max_connections = 10 # (change requires restart)
shared_buffers = 1536MB # min 128kB
work_mem = 256MB # min 64kB
maintenance_work_mem = 512MB # min 1MB
wal_buffers = 12MB # min 32kB
checkpoint_segments = 16 # in logfile segments, min 1, 16MB each
checkpoint_completion_target = 0.8 # checkpoint target duration, 0.0 - 1.0
effective_cache_size = 4GB
logging_collector = on # Enable capturing of stderr and csvlog
log_directory = 'pg_log' # directory where log files are written,
log_filename = 'postgresql-%a.log' # log file name pattern,
log_truncate_on_rotation = on # If on, an existing log file of the
log_rotation_age = 1d # Automatic rotation of logfiles will
log_rotation_size = 0 # Automatic rotation of logfiles will
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8' # locale for system error message
lc_monetary = 'en_US.UTF-8' # locale for monetary formatting
lc_numeric = 'en_US.UTF-8' # locale for number formatting
lc_time = 'en_US.UTF-8' # locale for time formatting
default_text_search_config = 'pg_catalog.english'>Pour une des requêtes qui sont très très longue;
rsyslog=> EXPLAIN ANALYZE SELECT * FROM systemevents WHERE fromhost = 'XXXX' ORDER BY id desc LIMIT 20 ;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------
---------
Limit (cost=0.00..26158.94 rows=20 width=957) (actual time=129134.836..131515.164 rows=20 loops=1)
-> Index Scan Backward using systemevents_pkey on systemevents (cost=0.00..94773822.13 rows=72460 width=957) (actual time=129134.833..131515.142 rows=20
loops=1)
Filter: ((fromhost)::text = 'XXXX'::text)
Total runtime: 131515.293 ms
(4 rows)
rsyslog=>Je suis entrain de coder pour faire un split des données dans plusieurs tables voir si cela arrangerais les choses.
en attendant d'avoir d'autres solutions.
à noté que si l'équipement et le nombre de ligne demandé sont dans les dernières la requete est très rapide mais ceux qui envoient beaucoup de log sont rarement ceux qui nous intéresse ^^
Bon j'ai essayer de faire sans la Pkid voir ce que cela donnais, mais cela ne m'arrange pas sauf dans les cas ou j'ai besoin d'information directement sur le host
car un simple :
SELECT receivedat,message FROM systemevents order by id desc LIMIT 25;dure 15ans alors qu'avant ne durais qu'une seconde 
faut que je trouve une autre solution
actuellement j'utilise une RedHat RHEL 6.2 x86_64
est-ce qu'une version plus récente que 8.4 existe ? d'après les liens de téléchargement directe j'en ai pas vue mais c'est peut être moi qui n'ai pas bien regardé
http://www.postgresql.org/download/linux/redhat/
je ne sais plus vraiment quoi regarder maintenant :x
ma dernière solution serrait de diviser en plusieurs tables
C'est le genre de raisons ou cela me soule les processus entreprise ><"
où les versions date d'il y a 5 ans.
L'idée est bien;
rsyslog=> EXPLAIN SELECT * FROM systemevents WHERE fromhost = 'XXXX' ORDER BY id desc LIMIT 10;
QUERY PLAN
-----------------------------------------------------------------------------------------------
Limit (cost=255199.89..255199.92 rows=10 width=957)
-> Sort (cost=255199.89..255376.89 rows=70797 width=957)
Sort Key: id
-> Bitmap Heap Scan on systemevents (cost=1680.96..253670.00 rows=70797 width=957)
Recheck Cond: ((fromhost)::text = 'XXXX'::text)
-> Bitmap Index Scan on nomequipement (cost=0.00..1663.26 rows=70797 width=0)
Index Cond: ((fromhost)::text = 'XXXX'::text)Bon par contre j'ai merder ^^',
Tu avais une erreur dans le mot CONSTRAINT, mais j'avais pas prévu qu'il m’arrête toute la procédure, donc quand je l'ai corrigé, le rollback n'était plus d’actualité 
est-ce que je ne peux pas la laisser supprimé? quel intérêt elle à dans mon environnement ? (je ne suis pas sur de saisir complément l’intérêt des index)
rsyslog=> ALTER TABLE systemevents ADD PRIMARY KEY (id);
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "systemevents_pkey" for table "systemevents"
ALTER TABLEj'ai augmenter le work_mem a 256M et le max connexion à 10
rsyslog=> EXPLAIN SELECT * FROM systemevents WHERE fromhost = 'XXXX' ORDER BY id desc LIMIT 10;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------
Limit (cost=0.00..13071.17 rows=10 width=957)
-> Index Scan Backward using systemevents_pkey on systemevents (cost=0.00..93162177.33 rows=71273 width=957)
Filter: ((fromhost)::text = 'XXXX'::text)
(3 rows)
rsyslog=>j'ai tester une requête sans le pkid, et elle était beaucoup plus rapide. la c'est revenu comme avant
Je te remercie pour l'aide que tu m'apportes
Il semblerait que cela vienne du ORDER BY id
rsyslog=> EXPLAIN SELECT * FROM systemevents WHERE fromhost = 'XXXX' LIMIT 10;
QUERY PLAN
---------------------------------------------------------------------------------------------------
Limit (cost=0.00..36.24 rows=10 width=957)
-> Index Scan using nomequipement on systemevents (cost=0.00..256534.19 rows=70797 width=957)
Index Cond: ((fromhost)::text = 'XXXX'::text)
(3 rows)
rsyslog=>Cela ne peux pas utiliser deux indexes ?
sur une recherche plus compliqué ça semble fonctionner
rsyslog=>
EXPLAIN SELECT * FROM systemevents WHERE fromhost = 'XXXX' AND devicereportedtime < '2014-03-01' AND devicereportedtime > '2014-04-01' ORDER BY id desc LIMIT 10;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=11074.79..11074.81 rows=10 width=957)
-> Sort (cost=11074.79..11075.67 rows=354 width=957)
Sort Key: id
-> Bitmap Heap Scan on systemevents (cost=9655.47..11067.14 rows=354 width=957)
Recheck Cond: (((fromhost)::text = 'XXXX'::text) AND (devicereportedtime < '2014-03-01 00:00:00'::timestamp without time zone) AND (devicereportedtime > '2014-04-01 00:00:00'::timestamp without time zone))
-> BitmapAnd (cost=9655.47..9655.47 rows=354 width=0)
-> Bitmap Index Scan on nomequipement (cost=0.00..1655.19 rows=70797 width=0)
Index Cond: ((fromhost)::text = 'XXXX'::text)
-> Bitmap Index Scan on timereporting (cost=0.00..7999.86 rows=380724 width=0)
Index Cond: ((devicereportedtime < '2014-03-01 00:00:00'::timestamp without time zone) AND (devicereportedtime > '2014-04-01 00:00:00'::timestamp without time zone))
(10 rows)
rsyslog=>Merci pour les indications
j'ai lancé l'analyze systemevents
rsyslog=> analyze systemevents;
ANALYZE
rsyslog=> EXPLAIN SELECT * FROM systemevents WHERE fromhost = 'XXXX' ORDER BY id desc LIMIT 10;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------
Limit (cost=0.00..13199.83 rows=10 width=957)
-> Index Scan Backward using systemevents_pkey on systemevents (cost=0.00..93450812.85 rows=70797 width=957)
Filter: ((fromhost)::text = 'XXXX'::text)
(3 rows)
rsyslog=>Pourtant l'index existe : (j'aime bien les commandes compliqué qui vont vite 
)
rsyslog=> select
rsyslog-> t.relname as table_name,
rsyslog-> i.relname as index_name,
rsyslog-> a.attname as column_name
rsyslog-> from
rsyslog-> pg_class t,
rsyslog-> pg_class i,
rsyslog-> pg_index ix,
rsyslog-> pg_attribute a
rsyslog-> where
rsyslog-> t.oid = ix.indrelid
rsyslog-> and i.oid = ix.indexrelid
rsyslog-> and a.attrelid = t.oid
rsyslog-> and a.attnum = ANY(ix.indkey)
rsyslog-> and t.relkind = 'r'
rsyslog-> and t.relname like 'systemevents'
rsyslog-> order by
rsyslog-> i.relname;
table_name | index_name | column_name
--------------+-------------------+--------------------
systemevents | nomequipement | fromhost
systemevents | systemevents_pkey | id
systemevents | timereporting | devicereportedtimeBon par contre je pense que le devicereportedtime ne sert a rien car j'ai que 8à20log/s sur 80M d'entrée ca fait pas pas beaucoup d’économie (me dire si je me trompe)
La plus part des requêtes seront
SELECT * FROM systemevents WHERE ORDER BY id desc LIMIT 25;
SELECT * FROM systemevents WHERE fromhost like 'XXXX%' ORDER BY id desc LIMIT 25;
SELECT * FROM systemevents WHERE fromhost = 'XXXX' AND devicereportedtime <'XXXX-XX-XX' AND devicereportedtime >'XXXX-XX-XX' ORDER BY id desc LIMIT 25;
SELECT * FROM systemevents WHERE fromhost = 'XXXX' AND facility <> 10 ORDER BY id desc LIMIT 25;La plus part du temps un host est indiqué entièrement ou presque
je vais corriger l'index car ça peux varier
pour la requête :
rsyslog=> EXPLAIN SELECT * FROM systemevents WHERE fromhost = 'XXXX' ORDER BY id desc LIMIT 10;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------
Limit (cost=0.00..11974.83 rows=10 width=957)
-> Index Scan Backward using systemevents_pkey on systemevents (cost=0.00..99273730.89 rows=82902 width=957)
Filter: ((fromhost)::text = 'XXXX'::text)
(3 rows)
rsyslog=>Cela permet de dire quoi ?
est-ce que VACUUM FULL est intéressant pour gagner en temps ? ou ça me permettra uniquement de gagner de l'espace disque ?
il n'y a normalement que 250/300 équipements différents, donc cela devrais pas gener, mais même sans %; j’attends encore le résultat de la commande que j'ai passé tout a l'heure
dès que je peux (j’attends la fin de l'autre requête je passe celle la :
par contre dois-je supprimer l'ancienne ou cela la remplace
CREATE INDEX CONCURRENTLY NomEquipement ON systemevents(fromhost varchar_pattern_ops);je n'ai pas le détail des requêtes que le logiciel utilise c'est pourquoi je fait mes test personnel :
je viens de rajouter un index sur le nom de l’équipement, après 3h d'attente de la réussite de la requête
CREATE INDEX CONCURRENTLY NomEquipement ON systemevents(fromhost);je test :
SELECT * FROM systemevents WHERE fromhost like 'XXXX' ORDER BY id desc LIMIT 10;mais j’attends encore le résultat
je vais augmenter ces paramètres
Bonjour,
Non malheureusement ce n'est pas que cette requête.
ni qui me pose des soucis de performance ni que j'effectue.
si j'effectue une requête précise :
SELECT * FROM systemevents WHERE id = 50000000;La requête est très rapide
par contre une requête de type
SELECT * FROM systemevents WHERE receivedat < '2014-03-14' AND receivedat > '2014-02-14' LIMIT 10;met autant de temps que de calculer le nombre de ligne si ce n'est plus
j'ai actuellement dans le 80M de ligne sur la table.
il n'y a pas de requête imbriqué.
ce qui m'embête en soit : c'est que pendant l’exécution des requête ni le CPU ni la RAM n'est à fond (30% de CPU et 7% de RAM)
donc j'ai l'impression de m'être tromper sur la conf.
Version de postgresql : 8.4.18
Cordialement
Dragondark de Lonlindil
ps : Je vais essayer de jouer avec les index semblerais que j'en ai pas (il me semblais en avoir mis)
Bonjour,
J'ai aujourd'hui monté un serveur Rsyslog sur une base de type Postgresql pour permettre la gestion et l'affichage des logs facilement.
Mais j'ai des soucis d'optimisation...
j'ai aujourd'hui un serveur RedHAT de 6G de RAM,
coté consommation cela ne semble pas énorme :
2153 postgres 20 0 962m 32m 31m S 0.0 0.6 0:02.22 postmaster
2174 postgres 20 0 966m 9m 8192 S 2.0 0.2 0:08.83 postmaster
2167 postgres 20 0 962m 7380 6620 S 0.0 0.1 0:00.30 postmaster
2172 postgres 20 0 964m 5600 3872 S 0.0 0.1 1:30.81 postmaster
mais une requête simple : SELECT count(*) FROM systemevents; prend énormément de temps (plus de 3 minutes)
il y a actuellement 75 000 000 lignes.
Configuration postgresql
listen_addresses = '*'
max_connections = 51 # (change requires restart)
shared_buffers = 756MB # min 128kB
work_mem = 30MB # min 64kB
maintenance_work_mem = 256MB # min 1MB
wal_buffers = 12MB # min 32kB
checkpoint_segments = 16 # in logfile segments, min 1, 16MB each
checkpoint_completion_target = 0.8 # checkpoint target duration, 0.0 - 1.0
effective_cache_size = 4GB
logging_collector = on # Enable capturing of stderr and csvlog
log_directory = 'pg_log' # directory where log files are written,
log_filename = 'postgresql-%a.log' # log file name pattern,
log_truncate_on_rotation = on # If on, an existing log file of the
log_rotation_age = 1d # Automatic rotation of logfiles will
log_rotation_size = 0 # Automatic rotation of logfiles will
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8' # locale for system error message
lc_monetary = 'en_US.UTF-8' # locale for monetary formatting
lc_numeric = 'en_US.UTF-8' # locale for number formatting
lc_time = 'en_US.UTF-8' # locale for time formatting
default_text_search_config = 'pg_catalog.english'Si vous avez des idées d'optimisation, c'est un serveur dedier, donc qu'il me consomme 95% de ma RAM ne me gene pas, tant qu'il me permet de travailler rapidement.
Si vous avez des questions n’hésitez pas!
Cordialement
Dragondark De Lonlindil
merci
pour ce qu'il en ai j'ai trouver la solution j'ai redefini mon /etc/init.d/postgresql-8.3.7 pour le mettre a jour en fonction de mes option de configure
puis je l'ai remplacer par /etc/init.d/postgresql
comme cela apache appel la fonction
/etc/init.d/postgres
et donc execute postgresql 8.3.7 en bonne version, et correctement
j'ai tout relance et ca marche a nikel 
merci
bonne soirée
alors en faite je vien de trouver mon probleme qui m'en donne un autre
j'ai reinstaller la version de postgres avec ces option
/configure --prefix=/usr --includedir=/usr/include/postgresql/pgsql --datadir=/home/postgres/data --sysconfdir=/etc/postgresql --mandir=/usr/share/man --host=x86_64-pc-linux-gnu --with-docdir=/usr/share/doc/postgresql-8.3.7/ --libdir=/usr/lib/ --enable-depend --enable-nls=all --with-perl --with-python --with-tcl --with-openssl --with-libxml --with-libxslt --enable-thread-safety
mais apparament
--datadir=/home/postgres/data
ne crée pas le dossier pour la base de donnée mais le dossier de configuration, ce qui m'implique un certain soucis etant donnée que maintenant mon dossier de configuration se trouve a la place de ma base de données
je l'ai donc reinstaller respectant cette option et creant ma nouvelle base dans data2/
et j'ai lancer le serveur qui se lance parfaitement
donc je pense qu'il me suffis de faire :
gmake uninstall
gmake clean
gmake cleandir
/configure --prefix=/usr --includedir=/usr/include/postgresql/pgsql --datadir=/usr/pgsql/data --sysconfdir=/etc/postgresql --mandir=/usr/share/man --host=x86_64-pc-linux-gnu --with-docdir=/usr/share/doc/postgresql-8.3.7/ --libdir=/usr/lib/ --enable-depend --enable-nls=all --with-perl --with-python --with-tcl --with-openssl --with-libxml --with-libxslt --enable-thread-safety
gmake
gmake install
initdb -D /home/postgres/datanon?
pour expliquer, j'ai du installer la version 8.0.15 car etant sous gentoo, c'est la seul version disponible
et dessus j'ai mis en place la version 8.3.7 manuelement
pour pouvoir enfaite renplacer toute les fichier executable du 8.0.15, et garder une hierarchie de gentoo
(j'ai repris l'ebuild du 8.0.15 pour l'install du 8.3.7)
c'est histoire de faire quelque chose de propres.
vis a vis des mis a jour et ... je ne sais plus quoi :s
par contre cette facon de faire engage que j'ai un soucis apres avec la coordination entre apache et ma base de donnée
car il fais appel a l'ancienne version,
je sais pas si vous avez une solution vis a vis de cette situation
car j'ai aussi remarquer que pour lancer le serveur il faut faire une ligne de commande et qu'on pouvais pas par /etc/init.d/postgres-8.3.7 start (qui apparament mene a rien)
faire un scritp faisant lancer le serveur/ le stoper et tout, c'est relativement simple (en y metant aussi deux ligne de commande et une syntaxe pour prendre en compte les argument)
mais cela fais que je n'aurais plus de fichier de lancement habituel.
donc si vous avez une alternative en tete je suis preneur
cordialement
dragondark
j'ai eu cette erreur
could not change directory to "/root"
initdb: file "/home/postgres/data/postgres.bki" does not exist
This might mean you have a corrupted installation or identified
the wrong directory with the invocation option -Ldonc j'ai pris le dossier data que j'avais dans
/postgresql/postgresql-8.3.7/src/test/regress/tmp_check/install/home/postgres/datasauf que maintenant j'ai une erreur du type :
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale C.
The default text search configuration will be set to "english".
creating directory /usr/local/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 10
selecting default shared_buffers/max_fsm_pages ... 400kB/20000
creating configuration files ... ok
creating template1 database in /usr/local/pgsql/data/base/1 ... FATAL: invalid value for parameter "timezone_abbreviations": "Default"
child process exited with exit code 1
initdb: removing data directory "/usr/local/pgsql/data"donc je en sais aps si vous avez une solution a me proposer :c
cordialement
dragondark
ps : tout vien de cette erreur
* Starting PostgreSQL ...
FATAL: database files are incompatible with server
DETAIL: The data directory was initialized by PostgreSQL version 8.0, which is not compatible with this version 8.3.7.
Probleme resolu
apparament mon pc, n'arrivais plus a compiller ce qui provoquais ces erreur.
surment une mauvaise manip de ma part, resolut grace a
http://www.gentoo.org/doc/fr/gcc-upgrading.xml
j'ai mis a jour gcc, qui a du recevoir un changement ou je ne sais pas, ce qui provoquai l'erreur
Bonjour
j'ai installer postgres par le passé (version 8.0.15, via l'emerge que propose gentoo), puis désinstaler pour installer dessus la version 8.3.7 manuelement.
elles fonctionnais parfaitement mais j'avais un probleme de librairie, donc par soucis de propreter, j'ai tout desinstaller.
puis j'ai voulu reinstaller la version 8.0.15 pour la mettre a jours avec la version 8.3.7. le probleme c'est que j'ai du cafouiller quelque part etant donné que maintenant quand je lance
#emerge postgresql
je tombe sur une erreur
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lpq
collect2: ld returned 1 exit status
make[4]: *** [libecpg.so.5.0] Error 1
make[4]: Leaving directory `/var/tmp/portage/dev-db/postgresql-8.0.15/work/postgresql-8.0.15/src/interfaces/ecpg/ecpglib'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/var/tmp/portage/dev-db/postgresql-8.0.15/work/postgresql-8.0.15/src/interfaces/ecpg'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/var/tmp/portage/dev-db/postgresql-8.0.15/work/postgresql-8.0.15/src/interfaces'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/var/tmp/portage/dev-db/postgresql-8.0.15/work/postgresql-8.0.15/src'
make: *** [all] Error 2
*
* ERROR: dev-db/postgresql-8.0.15 failed.
* Call stack:
* ebuild.sh, line 49: Called src_compile
* environment, line 2931: Called die
* The specific snippet of code:
* emake -j1 LD="$(tc-getLD) $(get_abi_LDFLAGS)" || die "main emake failed";
* The die message:
* main emake failed
*
* If you need support, post the topmost build error, and the call stack if relevant.
* A complete build log is located at '/var/tmp/portage/dev-db/postgresql-8.0.15/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/dev-db/postgresql-8.0.15/temp/environment'.
*
>>> Failed to emerge dev-db/postgresql-8.0.15, Log file:
>>> '/var/tmp/portage/dev-db/postgresql-8.0.15/temp/build.log'
* Messages for package dev-db/postgresql-8.0.15:
*
* ERROR: dev-db/postgresql-8.0.15 failed.
* Call stack:
* ebuild.sh, line 49: Called src_compile
* environment, line 2931: Called die
* The specific snippet of code:
* emake -j1 LD="$(tc-getLD) $(get_abi_LDFLAGS)" || die "main emake failed";
* The die message:
* main emake failed
*
* If you need support, post the topmost build error, and the call stack if relevant.
* A complete build log is located at '/var/tmp/portage/dev-db/postgresql-8.0.15/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/dev-db/postgresql-8.0.15/temp/environment'.d'apres ce que je peux voir
* emake -j1 LD="$(tc-getLD) $(get_abi_LDFLAGS)" || die "main emake failed";
* The die message:
* main emake failedca viendrais de la commande emake qu'il n'arrive pas a executer
donc j'ai regarde mon PATH :
# ld.so.conf autogenerated by env-update; make all changes to
# contents of /etc/env.d directory
/usr/local/lib
//usr/lib32/opengl/xorg-x11/lib
//usr/lib64/opengl/xorg-x11/lib
/lib
/usr/lib
/lib64
/usr/lib64
/usr/local/lib64
/lib32
/usr/lib32
/usr/local/lib32
/usr/x86_64-pc-linux-gnu/lib
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/32
/usr/lib64/nspr
/usr/lib64/nss
/usr/lib64/qca1
/usr/lib/qt4
/usr/lib64/qt4
/usr/lib32/qt4
/usr/kde/3.5/lib
/usr/kde/3.5/lib64
/usr/kde/3.5/lib32
/usr/qt/3/lib
/usr/qt/3/lib64
/usr/qt/3/lib32on peux voir qu'il est senser en faire partis :
je regarde ma variable PATH pres un
#env-update
#echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.2:/usr/kde/3.5/sbin:/usr/kde/3.5/bin:/usr/qt/3/binet la on peux remarquer qu'il en manque. et je ne sais pas pourquoi :s
en esperant que cela vienne de là
c'est pourquoi je demande si vous pouvez me dire si cela viens bien de la,
et si vous avez une solution a me proposer
cordialement
dragondark
Pages : 1