Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Sur la plupart de mes instances Postgresql, j'ai une activité normale, mais depuis près d'un mois, plus aucune trace dans le journal... et d'habitude, couplé à une réplication, c'est assez verbeux.
Je ne trouve pas, dans le fichier de conf, s'il est possible de configurer une taille maximale, un journal tournant ou quelque chose du style, mais j'ai sans doute dû passer à côté...
Le volume n'est pas plein...
Une idée ?
D'avance merci
Fabien
Dernière modification par fadace (07/03/2011 16:39:25)
Hors ligne
Bonjour,
Pour commencer, quelle version de PG ?
Ensuite, si elle est récente, que vaut logging_collector et log_destination ?
Marc.
Hors ligne
Ah oui, désolé, l'empressement...
PG v. 8.3 sur Aix.
#log_destination = 'stderr'
#logging_collector = off
log_truncate_on_rotation = off
Ceci étant dit, ils ont toujours été dans cet état.
Hors ligne
Ok. J'ai pas dit qu'ils étaient pas dans cet état avant, c'est juste que la stratégie n'est pas la même suivant la façon de collecter les logs 
À priori, donc, postgresql envoie 'bêtement' son stderr, qui doit être redirigé vers un fichier (sauf autre option passée à pg_ctl au démarrage).
Si vous avez supprimé le fichier, je pense que vous ne vous en sortirez pas sans redémarrer le moteur. Si vous redirigez le stderr, vous devez utiliser un script ou logrotate en mode «copytruncate».
À mon avis, en ce moment, vous avez un fichier supprimé, mais toujours présent, dans lequel PostgreSQL continue d'envoyer sa log.
Marc.
Hors ligne
Je n'ai pas supprimé le fichier.
Je l'ai juste purgé.
Le no d'inode n'a pas été modifié.
La journalisation ne reprend pourtant pas.
Le redémarrage a bien évidemment résolu le problème, mais j'aurai souhaité connaître la cause du problème...
m.s.
Hors ligne
Si juste purgé, ça n'aurait pas du. Ça ne le fait d'ailleurs sur aucun système que j'administre
Plus sérieusement, avec quelle commande de purge ?
Marc.
Hors ligne
Edité avec vi,
Supprimé n-10 lignes
Sauvé avec :x
... et je confirme, ça ne me l'a jamais fait... mais sur le coup, en l'intervalle de 2 semaines, j'ai ma base de prod et ma base de staging qui ont fait la même chose.
Hors ligne
J'avais jamais fait attention que vi gardait le même numéro d'inode. Je ne parierais pas là dessus dans tous les cas d'ailleurs, même si effectivement ça a l'air d'être le cas. Il doit bien y avoir des cas où il réécrit un autre fichier.
Ce que j'ai vu faire, habituellement, pour remettre un fichier à zéro, c'est une commande comme:
echo "" > fichier_a_remettre_a_zeroMarc.
Hors ligne
A ma connaissance, vi fait un fopen du fichier.... donc il devrait avoir de la peine à ne pas garder le même no d'inode... à l'execption notable de la "save as..." (w nonFichier!)
Je serai attentif si le problème se reproduit...
m.s.
Hors ligne
Pages : 1