Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#1 Re : Général » Réinstallation de PostgreSql 8.4 » 05/11/2010 09:21:25
Bonjour et merci pour ce post car cela à également réglé mon problème.
1) Par contre quelqu'un saurait il dans quel cas on peut se retrouver avec un postmaster.pid vide ou corrompu qui empeche le démarrage de postgres?
2) Pour ma part, je pense avoir peut être éteint brutalement la machine sans arréter le service PostGres correctement. Est-ce que cela peut en être la cause?
3) Si je supprime automatiquement le postmaster.pid au démarrage, après ce type plantage par exemple, je risque de perdre des données dans ma base?
Merci à tous
#2 Re : Optimisation » VACUUM ne démarre pas » 22/07/2010 11:08:57
OK, c'est donc le VACUUM qui modifie des choses dans la table
#3 Re : Optimisation » VACUUM ne démarre pas » 22/07/2010 11:05:46
Marc, je n'avais pas pensé à faire un VACUUM verbose. Je viens de le faire, et je me demande si ces informations ne sont pas utiles :
CPU 0.00s/0.00u sec elapsed 0.00 sec.INFO: vacuuming "public.CTX_HISTORY"
INFO: index "CTX_HISTORY_pkey" now contains 4982 row versions in 3071 pages
DETAIL: 0 index row versions were removed.
3054 index pages have been deleted, 3054 are currently reusable.
CPU 0.02s/0.02u sec elapsed 65.57 sec.INFO: "CTX_HISTORY": found 0 removable, 4982 nonremovable row versions in 26 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
1 pages contain useful free space.
0 pages are entirely empty.
Ca fait beaucoup de pages non?
#4 Re : Optimisation » VACUUM ne démarre pas » 22/07/2010 10:45:08
Je n'ai pas essayé de reproduire sur une base vierge... Par contre j'ai déjà restauré la base plusieurs fois et le problème est toujours là.
Je fais un simple VACUUM ANALYSE, (de toute manière même un VACUUM tout court pose problème), et je ne comprends pas pourquoi je me retrouve avec un RowExclusiveLock dans la vue pg_locks...
Je tiens aussi a préciser que le RowExclusiveLock n'est pas forcément toujours sur la même relation. Tout à l'heure c'était sur CTX_DICT_pkey je crois, maintenant c'est sur CTX_HISTORY_pkey...
#5 Re : Optimisation » VACUUM ne démarre pas » 22/07/2010 10:07:28
#6 Re : Optimisation » VACUUM ne démarre pas » 22/07/2010 09:29:33
Pour mon diagnostique :
1) Sur une session, la #1, je démarre une transaction, suivi d'un appel à ma procédure stockée (qui produit la jointure).
2) Sur une autre session, la #2, je lance un VACUUM. Rien ne se passe, la commande est en cours d'exécution. Je peux la laisser des heures, rien ne changera.
3) Je fais "END;" sur la session #1.
4) Le VACUUM s'achève tout de suite sur la session #2.
Pour les valeurs que vous me demandez, ce sont celles par défaut :
#vacuum_cost_delay = 0 # 0-1000 milliseconds
#vacuum_cost_page_hit = 1 # 0-10000 credits
#vacuum_cost_page_miss = 10 # 0-10000 credits
#vacuum_cost_page_dirty = 20 # 0-10000 credits
#vacuum_cost_limit = 200 # 1-10000 credits
#7 Re : Optimisation » VACUUM ne démarre pas » 22/07/2010 09:14:49
Il n'y a rien en granted à false.
Par contre je pense que ceci peu vous intéresser : Une fois le vacuum lancé et bloqué, je fais un select pg_locks joint avec pg_class et un RowExclusiveLock apparait :
----;------;---------;---------
pid;mode;granted;relname
----;------;---------;---------
1272;"RowExclusiveLock";t;"CTX_DICT_pkey"
1272;"ShareUpdateExclusiveLock";t;"CTX_DICT"
le pid 1272 correspond à la session qui appelle le VACUUM.
En tout cas merci pour votre aide
#8 Re : Optimisation » VACUUM ne démarre pas » 22/07/2010 08:52:12
En fait j'ai regardé avec pg_locks et je n'ai rien trouvé d'aberrant.
Les relations utilisées pour la transaction #2 (celle qui pose problème), ressemblent aux relations utilisées pour la transaction #1 (celle qui ne pose pas problème), mais avec des noms de table différents, ce qui est normal. Il n'y a aucun verrouillage exclusif (à part des locktype virtualxid qui posent un ExclusiveLock, mais je suppose que c'est dû à la vue pg_locks ?).
J'ai remarqué autre chose d'intéressant :
Concernant la transaction qui pose problème, si la table utilisée ne contient que peu d'enregistrements, je n'ai pas de problèmes pour le VACUUM. Dès qu'un certain nombre d'enregistrement est atteint (a peu pres 500, voire moins), le VACUUM bloque.
#9 Optimisation » VACUUM ne démarre pas » 21/07/2010 18:58:50
- slash
- Réponses : 14
Bonjour,
Je rencontre actuellement un petit souci et j'aimerai vous en faire part :
J'effectue une requête de jointure à l'intérieur d'une transaction qui n'est pas terminée (pas de END;). Jusque là pas de souci.
Ensuite, sur une autre connexion, je viens faire un VACUUM. Et la je constate que le VACUUM ne se termine pas (il attend apparemment).
Lorsque je cloture la transaction sur l'autre connexion, le VACUUM s'achève bien.
Mon problème c'est que j'ai deux requêtes de jointure, sur 2 connexions différentes, et qui ne sont jamais terminées, sauf si j'en démarre une nouvelle.
La première requête ne pose aucun problème vis à vis du VACUUM, tandis que la deuxième bloque le VACUUM. Sauriez vous pourquoi?
Si vous avez une idée de où cela pourrait il venir, j'en serai fort intéressé!
Merci d'avance!
#10 Re : Général » Performance VUE/Procédure stockée » 09/04/2010 08:55:28
Merci beaucoup!
#11 Re : Général » Performance VUE/Procédure stockée » 08/04/2010 14:34:13
Bonjour,
je me rends compte que j'ai omis de parler de quelque chose :
La procédure stockée que j'utilise génère un curseur que j'utilise ensuite pour récupérer les données.
- Avec cette méthode, la procédure stockée a-t-elle des chances d'etre plus performante que la vue?
- Peut on faire des curseur sur des vues?
#12 Re : Général » Performance VUE/Procédure stockée » 06/04/2010 13:38:14
Ok, merci beaucoup pour ces informations!
#13 Général » Performance VUE/Procédure stockée » 06/04/2010 12:24:54
- slash
- Réponses : 6
Bonjour à tous,
Quelqu'un pourrait il m'éclairer sur ce sujet s'il vous plait? =>
J'ai une base de données embarquée sur un système Windows XP Embedded, sur laquelle je fais régulièrement des requêtes de jointures de jointure (un peu moins de 10 tables).
Ce processus est actuellement effectué par une procédure stockée, via laquelle je peux passer des arguments, de telle sorte a filtrer mon résultat.
Ma question :
Si, au lieu de faire la jointure des tables dans la procédure stockée, je l'effectue via une vue sur laquelle j'appliquerai mes filtres, est-ce que les performances (temps de reponse/charge CPU) seront plus faibles que par la méthode de la procédure stockée? Ou est-ce que j'aurai l'effet inverse?
D'avance merci,
Cordialement,
Mat
#14 Re : Général » Journaux de transaction WAL » 05/06/2009 13:30:43
J'avais déjà lu cette doc, mais maintenant en la relisant plus attentivement, je pense qu'en jouant sur checkpoint_segments, je peux éviter ce problème.
Gleu, a l'heure actuelle, en effet c'est problématique, mais nous attendons une configuration avec un espace de plus de 500mo libre (toujours sur compact flash...)
Je n'avais jamais entendu parlé de SQLite, je vais y jetter un oeil!!
#15 Re : Général » Limiter nombre d'enregistrements/table ou taille de table » 05/06/2009 11:28:20
oki oki! bon bah on va rester sur le bon gros trigger alors ;-)
Merci encore gleu!
#16 Général » Journaux de transaction WAL » 05/06/2009 11:16:11
- slash
- Réponses : 3
Bonjour,
J'utilise une petite base PostGreSQL sur un Windows XP Embedded, et autant dire tout de suite que j'ai très très peu d'espace disque pour le moment.
La base tournait parfaitement, jusqu'a ce que je test l'insertion de beaucoup d'enregistrements d'un coup dans une table, jusqu'a avoir une erreur : espace disque plein.
J'ai ensuite violemment coupé l'alimentation et redémarré.
Problème : postgres ne démarre plus, et je n'ai pas de logs dans pg_log.
Je remarque que sur mon disque, il me reste 0 octet de libre (j'avais prévenu que j'avais pas grand chose ;p).
Je remarque également que j'ai 2 fichiers dans pg_xlog. 2 fichiers de 16mo qui prennent toute la place dont j'ai besoin.
En fait, quand postgres fonctionnait bien, je n'avais qu'un fichier de 16mo dans pg_xlog. Depuis que postgres m'a créé ce 2e fichier, il a pris la place disque restante et ne peut plus démarrer.
2 questions découlent de mon pb :
- Pourquoi postgres m'a créé un 2eme fichier WAL?
- Quand est ce que ces fichiers sont supprimés?
Merci à vous! 
#17 Re : Général » Limiter nombre d'enregistrements/table ou taille de table » 05/06/2009 10:49:05
Hm, je suis sous un Windows XP Embedded et ce module n'a pas été implémenté...
Il n'y a pas de fonction interne a PostGreSQL capable de faire çà d'une façon ou d'une autre, sans passer par une configuration Windows?
#18 Re : Général » Limiter nombre d'enregistrements/table ou taille de table » 05/06/2009 10:32:39
on peut régler des requêtes périodiques?
#19 Re : Général » Limiter nombre d'enregistrements/table ou taille de table » 05/06/2009 08:57:25
Oui mais on ne veut perdre aucune information si aucun insert n'arrive. On souhaite avoir le meme principe qu'un buffer tournant...
#20 Re : Général » Limiter nombre d'enregistrements/table ou taille de table » 04/06/2009 18:17:13
pas du tout, c'est une limite que nous nous sommes imposée délibérément
en tout cas merci pour vos réponses!
#21 Re : Général » Limiter nombre d'enregistrements/table ou taille de table » 04/06/2009 18:03:39
la table logge des évènements, et devrait contenir au maximum 2000 enregistrements. Pour le moment j'ai fait un trigger, qui a partir de 2000 enregistrements, supprime le plus vieux et ajoute le nouveau.
Je ne constate pas encore de gros ralentissement, mais j'imagine le jour ou on demande d'avoir la possibilité d'avoir 100000 enregistrements, là je pense qu'il y aura problème.
#22 Général » Limiter nombre d'enregistrements/table ou taille de table » 04/06/2009 15:23:28
- slash
- Réponses : 13
Bonjour,
Est il possible de limiter le nombre d'enregistrements que pourrait contenir une table? (sinon limiter la taille?)
Et si oui, écraser les plus anciens enregistrements lors de l'ajout d'un nouvel enregistrement ? (genre de buffer tournant)
Merci à vous!
#23 Re : Optimisation » temps de traitement d'une requete » 27/03/2009 17:10:50
hm, je pense que je perds du temps sur les requetes d'UPDATE etc...
Est-ce que l'utilisation d'un Trigger accélérera les choses?
En fait avant chaque nouveau INSERT, je dois faire quelques tests :
- Si un enregistrement de meme code (c'est un historique) est déjà présent et ne possède pas de date de fin, alors je mets une date de fin
- J'incrémente le champ "occurence"
et pour finir j'insère mon nouvel enregistrement avec la bonne information dans le champ occurence.
#24 Optimisation » temps de traitement d'une requete » 27/03/2009 16:39:28
- slash
- Réponses : 3
Bonjour tout le monde,
Je rencontre un problème de performances sous PostGreSQL : j'ai une fonction PostGreSQL (InserttoDB) qui se charge de faire un UPDATE, puis un INSERT puis un UPDATE. Je la lance depuis un programme C, et je vois que plus ma base se remplit, plus la requete InserttoDB est longue à faire. J'ai actuellement 130 enregistrements dans ma table, et un INSERT me prend entre 2 et 3 secondes!!
Est-ce normal que cela soit si long??
D'avance merci,
Mat.
#25 Général » Transactions (pour curseurs) parallèles, sur une même connexion » 10/03/2009 12:32:24
- slash
- Réponses : 1
Bonjour,
N'ayant pas trouvé de post à ce sujet, j'en démarre un ;o)
Est-ce qu'il est possible, sous PostGreSQL, d'avoir plusieurs transactions en parallèles sur une même connexion?
J'explique en détail le contexte du problème :
Je développe en C (libpq), un client qui, une fois connecté à la base, effectue des requêtes asynchrones.
Ces requêtes sont des appels à une procédure stockée qui me renvoie un curseur, pour que je puisse ensuite naviguer entre les résultats.
L'appel à la procédure stockée, sous le programme C est rendue asynchrone. Deux appels successifs sont effectués à ma procédure stockée, mais le nom du curseur, que je passe en paramètre est différent.
Une fois que mes deux curseurs sont établis, plus loin dans mon programme, j'aimerai, à ma guise, me balader dans les résultats pointés par les 2 curseurs.
Si je comprends bien le concept des curseurs, je fois faire l'initialisation du curseur, et son utilisation dans la même transaction. Or, dans mon cas, j'ai 2 appels du programme C, avec donc 2 curseurs différents, pour 2 requêtes SQL différentes (qui est un paramètre de ma procédure stockée), sur 1 seule procédure stockée. Donc si je termine ma transaction, mes 2 curseurs sont affectés.
J'aimerai donc dissocier l'initialisation de mes 2 curseurs, dans 2 transactions bien distinctes.
Est-ce possible?
Avez vous une autre idée?
Merki!!