Discussion :

[GGMSS]

Bonjour à tous,
Je suis nouveau sur le forum et j'ai un problème qui me bloque déja depuis 2 jours, en espérant que la communauté pourra me venir en aide.

Alors j'ai postgresql V 8.3.7 installé sur deux machines HP-UX et depuis déjà un an j'ai une base de données qui tourne bien dessus. j'ai fait un script d'évolution de ma base(création de 32 nouveaux champs dans une des tables et leur initialisation à des valeurs par défaut). cette table contient envriron 2000*65 lignes de données. je fais mes DEV sur un environnement windows sur le quel le script(durée exécution environ 30min) est passé sans problème et j'ai bien mes nouveaux champs, données et accès à la base sans soucis. Quand j'essaye de passer le même script sur mon environnement d'intégration qui lui est sur un machine HP-UX, postgresql crashe au bout d'un moment et une fois crashé, le simple fait de taper la commande psql me renvoie :

psql: could not connect to server: Fichier ou répertoire inexistant
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5435"?

sur la même machine, j'ai un 2e utilisateur postgres configuré sur le port 5433, quand je me connecte avec cet utilisateur et que je tape psql, je n'ai aucune erreur et j'arrive à accéder à la base de données configurée pour cet utilisateur

Les 2 utilisateurs sont configurés pour des projets différents. j'ai essayé de regarder dans PGDATA pour chacun d'entre eux, dans le cas du 1er utilisateur il manque le fichier postmaster.pid et quand je regarde ds /tmp .s.PGSQL.5435 n'existe pas tandis que .s.PGSQL.5433 existe bien. A noter que ces 2 fichiers existaient bien avant le crash pour l'utilisateur 1

Quand je fais pg_ctl status avec l'utilisateur 1, => pg_ctl: no server running
Quand je fais pg_ctl status avec l'utilisateur 2, =>pg_ctl: server is running (PID: 2511)
/opt/iexpress/postgresql/bin/postgres

j'ai essayé un pg_ctl start avec l'utilisateur 1, => server starting mais dès que je refais pg_ctl status => no server running

Je suis allé regarder dans les logs postgres j'ai ça :

HINT: Consider increasing the configuration parameter "checkpoint_segments".
LOG: duration: 22794.768 ms statement: ALTER TABLE Nomtable ADD COLUMN Nom_Colonne_15 INTEGER DEFAULT '65', ADD CONSTRAINT
Nomtable_fkey FOREIGN KEY (nomChamp)^M
REFERENCES Nomtable (id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION ;
LOG: checkpoints are occurring too frequently (15 seconds apart)
HINT: Consider increasing the configuration parameter "checkpoint_segments".
cp : copie erronée dans /nomrepertoire/archives/00000001000000080000009E : write: Plus d'espace dans le périphérique
LOG: archive command failed with exit code 1
DETAIL: The failed archive command was: cp pg_xlog/00000001000000080000009E /nomrepertoire/archives/00000001000000080000009E
cp : impossible de créer /nomrepertoire/archives/00000001000000080000009E : Autorisation refusée
LOG: archive command failed with exit code 1


LOG: database system was shut down at 2013-06-25 17:11:19 METDST
LOG: could not open file "pg_xlog/0000000100000008000000D8" (log file 8, segment 216): Fichier ou répertoire inexistant
LOG: invalid primary checkpoint record
LOG: could not open file "pg_xlog/0000000100000008000000D7" (log file 8, segment 215): Fichier ou répertoire inexistant
LOG: invalid secondary checkpoint record
PANIC: could not locate a valid checkpoint record
LOG: startup process (PID 19136) was terminated by signal 6
LOG: aborting startup due to startup process failure

j'ai fait un bdf, je me suis rendu compte que j'avais un file system qui etait saturé à 100%, je l'ai vidé. le problème c'est que depuis le crash je n'arrive plus à relancer postgres avec l'utilisateur 1 donc très embêté pour tester à nouveau.

A noter que le script de modification de la base a été lancée sur les 2 machines HP-UX et j'ai rencontré le même problème.

Dans l'attente de votre aide, je me tiens à votre disposition en vous remerciant d'avance.

[estofilo]

Apparemment il y a une corruption dans les fichiers WAL (journaux de transaction) suite à la saturation de l'espace disque. En mode récupération suite à crash, postgres utilise ces fichiers pour revenir là où il en était au moment du crash.
Il faudrait utiliser pg_resetxlog pour les supprimer.

La saturation elle-même vient du fait que le mode archivage est activé alors qu'il n'y a pas assez d'espace disque pour supporter ce mode, ou que les fichiers archivés ne sont jamais supprimés.

[GGMSS]

Merci estofilo
j'ai fait un pg_resetxlog -f repertoireData et tout semble être bien reparti. Nouveau fichier pid crée , serveur postgres redemarré après avoir fait un pg_ctl restart etc etc...

J'aimerai savoir comment ou que faire pour ne plus rencontrer ce problème lors de l'exécution de mon script?ya t-il un paramètre à modifier dans la config? car ce n'est aps moi qui ait configuré le serveur postgres

Merci

[estofilo]

De deux choses l'une: soit archive_mode a été mis à ON par erreur, soit volontairement.
Dans le premier cas il faut le mettre à OFF, dans le second cas il faut qu'un admin chargé de cette instance revoie la politique d'archivage vu qu'elle conduit à un plantage.

[GGMSS]

J'ai regardé le fichier postgresql.conf et il n'y a pas la ligne archivage_mode
Pour mieux identifier la source du problème j'ai relancé mon script et au fur et à mesure de l’exécution du script, j'ai régulièrement fait un bdf et là surprise j'ai un répertoire qui s'agrandit très vite et quand il atteint 100%, l'exécution du script s'est arrêté et j'ai de nouveau eu l'arrêt du serveur postgres comme dans ma question initiale avec les mêmes log. et quand je regarde le répertoire, il ne contient que les WAL. Le problème vient donc de l'archivage de la base comme tu me l'avais bien signifié. Alor je me dis peut être que je devrais rajouter la ligne archivage_mode = OFF dans mon fichier postgresql.conf, refaire un pg_resetxlog et relancer le serveur. Si ma requête se termine bien, j'arrête le serveur et je retire la ligne rajoutée avant redémarrage?
Je ne suis plus en mesure aujourd'hui de contacter la personne qui a configuré le serveur donc je ne saurai jamais pourquoi les choses ont été ainsi faites.

Encore merci

[estofilo]

C'est archive_mode (pas archivage_mode).

Ce qui me fait dire qu'il est activé, c'est ce genre de message:

cp : copie erronée dans /nomrepertoire/archives/00000001000000080000009E :
 write: Plus d'espace dans le périphérique
LOG: archive command failed with exit code 1
DETAIL: The failed archive command was:
 cp pg_xlog/00000001000000080000009E /nomrepertoire/archives/00000001000000080000009E

qui pointe très clairement sur l'archivage.

Il doit aussi y avoir une entrée archive_command
Voir la doc 8.3 pour plus d'information:
et spécifiquement ce chapitre: 18.5.3. Archivage

S'il n'y a pas de volonté d'utiliser les fichiers archivés pour de la sauvegarde incrémentale, l'archivage n'a pas d'intérêt.

Mais puisqu'il s'agit d'un environnement d'intégration, une question se pose. Si l'environnement de production a la même configuration et les mêmes problèmes d'espace disque, le script testé fera planter aussi la production.

[GGMSS]

Merci encore pour ton aide qui m'a été très précieuse.
J'ai mis archive_mode = off mais ça n'a rien changé toujours le plantage dès que le file system atteint 100%

je vais continuer à creuser. le problème initial étant résolu, je tiens donc à te remercier infiniment,

Cordialement