Vous n'êtes pas identifié(e).
Il ne manquerait pas une question ?
La question est comment puis je resoudre cette erreur ?
Des .Bin ont t'il deja été installé avac la kubuntu a partir de la version postgres 9
Est t'il preferable que j'installe debian ?
Merci
testé sur 2 machines
la premiere avec kubuntu version 9
at la seconde machine avec la version 11
lorsque je lance le .bin et que je coche postgis une erreur apparait
L'installation de PostGIS 1.5 for PostgreSQL 9.1 a renvoyé une erreur.
Cliquer sur le bouton « OK » pour ignorer cette erreur et continuer avec le reste des installations. Cliquer sur « Annuler » pour annuler le reste.
Notez qu'ignorer cette erreur pourrait résulter en des échecs des installations suivantes qui pourraient dépendre de ce paquet.
merci
ah ces docs !!
merci
dans /etc/rc0.d
j'ai un K20postgresql-9.0
est ce sript qui lance postgres au demarrage?
merci
Bonjour,
mon data est monté en NFS sur un nas (je sais que ce n'est pas recommandé , merci JP )
Lorsque ma debian demarre il met mets un message d'erreur
sh /user/donnees_pg/pgeom/data/pg_log/startup.log
(il ne trouve pas startup.log)
(j'ai l'impression que mes montages qui sont dans /etc/fstab ne se monte pas et il sort cet erreur )
pour verifier j'aimerais desactiver le demarrage auto de postgres
et le faire manuellement avec un
cd /etc/init.d
./postgresql-9.0 start
pour la lancement auto de postgres ou est ce?
je suis aller dans /etc/rc.local je n'ai rien vu
Merci
j'ai supprimer les filenode orphelins (avec oid2name ou aucune table ets référencé ) et cela marche
merci
malheureusement non on est toujours a 7 giga d'espace libre
la create table myschema.infoparc_sample n'a jamais été crée ce qui est normal
Cette requete a pris tout l'espace disque .
Il faudrez peut etre forcer le bgwriter pour qu'il nettoie mais comment ?
ou autre solution , le probleme est vraiment pointu !
merci d'avance
drop table myschema.infoparc_sample ;
create table myschema.infoparc_sample as
select a.id_parc,a.the_geom,X(a.centroide),Y(a.centroide),b.distvill, b.drp, b.drs, b.dgare,b.dzconst, b.dsurf_eau , c.dist_bat_majic, d.dist_bat_pci,e.dr
from infoparc2010.infop_dist as a
left join
myschema.distance as b on (a.id_parc=b.id_parc)
left join myschema.distance_majic as c on (a.id_parc=c.id_parc)
left join myschema.distance_pci as d on (a.id_parc=d.id_parc)
left join myschema.distance_chemin as e on (a.id_parc=d.id_parc)--- erreur était ici sur d.id_parc au lieu de e.id_parc --> ce qui a conduit à un table gigantesque (la table infoparc2010.infop_dist contient 250 000 obs)
where substr(a.id_parc,1,5) in (select id_insee from myschema.sample1_com);
c'est une requete avec une mauvaise jointure sur une autre table encapsulé dans un create table qui ne sait jamais fait
merci
c'est une mauvaise requete qui s'est passé confirmation à ce jour , toujours 900 giga de plein
est ce que ces valeurs
shared_buffers = 512MB
fsync = on
synchronous_commit = off
wal_writer_delay = 2000ms
checkpoint_segments = 20
checkpoint_timeout = 1min
checkpoint_completion_target = 0.8
checkpoint_warning = 1min
bgwriter_delay = 10ms
bgwriter_lru_maxpages = 1000
bgwriter_lru_multiplier = 10
peuvent resoudre mon probleme??
a ce soir j'ai regardé la taille schemas, des tables, des index < 200 giga
et dans mon data \base\72952 j'ai 900 giga donc espace libre de mon mountage de 8 giga
les filenode sont entassé dans ce repertoire a coup de 1giga ( donc au total 900 giga)
j'ai fait un vacuum rien n'y fait , le bgwriter y a longtemps qu'il aurait fait le menage !!
une piste ???? merci
ok pardon ne serait pas sshmax que j'ai modifié a 20 giga
merci
Bonjour,
je lance un vaccum avec 20 giga d'espace libre , je n'ai plus d'espace libre
je redemarre linux debian
je fais un df -h toujours a O%
je fais un demarrage de postgres il ne veut pas, donc postgres arrété
j'attends ........ quelques minutes
postgres est toujours arrete je refais un df -h je recupere 13 giga
y a t'il un demon en tache de fond que postgres utilise meme si postgres n'est pas demarré ?
Merci
bon je comprends plus ces filenode ne sont pas referencés dans pg_class
et ca fait un jour qu'ils sont dans dans ce repertoire cela me sature mon espace disque
comment puis je faire ?
merci
Bonsoir,
je suis en train de faire un vacuum full
mais le vaccum me prends de l'espace disque
et je suis a o%
comment faire ?
merci
mercii mais le probleme et que j'ai beaucoup de fichiers filenode "orphelins" de 1 giga
c'est une requete geometrique qui s'est mal passé et cela sature la base de données .
Quand postgres va les enlever ? comment ? avec autovaccum a on ?
Avez vous une doc sur ce type de probleme
merci
bonjour,
j'ai un fichier 4441919 (1giga) dans data/base/72952 quand je fais
./oid2name -d eco -U postgres -f 4441919
il ne le trouve pas , surement car j'ai une grosse requete qui s'est mal passé
Puis je supprimer ce fichier
Sinon comme Faut t'il gerer les filenode orphelins ?
merci
parfois avec oi2dname il me renvoie aucun nom de table
comme supprimer les filenode obsoletes (orphelin)
merci
mes tables crées par les utilisateurs n'ont pas de probleme 150 giga
si je fais SELECT pg_database_size('base'); j'ai 950 giga
a priori j'ai regardé avec oi2dname au niveau filenode il me renvoie comme table pg_toast_2604_index
c'est les pg_toast qui me prenne de la place comment on fait pour liberer de l'espace ?
je ne comprends pas je fais
sELECT schemaname as schema ,tablename as table,
pg_total_relation_size(schemaname||'.'||tablename) as size,
tableowner from
pg_tables order by size desc;
et la table la plus importante est de 7 giga
je fais la somme en taille de toutes les tables je trouve 106 giga
quand je fais SELECT pg_database_size('base'); 950 giga
donc y a pas une table temporaire , une table systeme qui est elevé en taille ???
quand une requete se passe mal avec un create table , les données sont mis surement
au prealable dans une zone tampon et on me dit que si ca se passe mal
postgres supprime automatiquement cette memoire cache
merci
Bonsoir,
Ma base de données postgres est de 150 giga ,.
le data se trouve sur un NAS qui fait 950 giga .
Mes dumps font 30 giga .
Ce soir le nas etait plein 950 giga , donc la base postgres
ne repondait plus espace libre a O%
Donc j'ai supprimé mes dumps ce qui m'a fait 20 giga de libre.
J'ai pu redemarré postgres ( en redemarrant la machine linux)
j'ai verifié la taille de mes tables , le tout fait 150 giga , donc je ne comprenais pas.
J'ai regardé dans le repertoire base , il existe un repertoire qui s'appelle 27522 ( qui fait 920 giga !!!)
dans ce repertoire il y avait plein de fichier qui font 1giga chacun .
j'ai regardé dans les logs il y a une requete de distance qui s'est mal passé la nuit .
Pourtant mon autovaccum est a ON .
pourquoi ces fichiers dans base sont crées par tranche de 1 giga .
y a t'il une valeur a diminuer dans postgres.conf ????
Par quelle etape dois je commencer pour trouver ce probleme
Grand merci
ok merci
1)
donc il vaut mieux faire
create table t1
puis faire des inserts de la grosse table vers t1
plutot
que
create table matablet1 as select * from grossetable
2)
j'ai le autovacum a on ce n'est pas genant ?
merci
comment puis je contourner ???
existe t'il une commande qui annule toutes les transactions
(requete en cours des utilisateurs )
de tous le utilisateurs afin que le pg_dump puisse se lancer automatiquement ?
Comment font les autres utilisateurs qui sauvegarde a 3 heures du matin mais
un utilisateur a lancer une une grosse requete qui est en train de tourner ?
merci
