Vous n'êtes pas identifié(e).
Pages : 1
Bonsoir ADMIN,
dans ce cas que dois-je faire puisqu'à l'heure où je vous écrit la base est arretée
Bonjour ADMIN,
bien noté, je regarde
Bonjour,
J'ai constaté que ma base de données ne démarrait pas .
Après investigation je me suis rendu compte qu'il n'y avait plus d'espace et cela est dû au fait que le répertoire "pg_wal" occupait tout l'espace à cause des fichiers journaux.
J'ai tout de suite désactivé l'option dans le fichier de configuration de postgresql.
Cependant je voudrais savoir si je peux supprimer les fichier du répertoire "pg_wal"?
Est ce qu'il n'y aurait pas d'impact sur la base de données?
Merci d'avance
Bonjour Admin.
Oui c'est un serveur Linux avec Sytemd et avec un utilisateur dont l'uid est supérieur à 1000
Bonjour Admin
Mon serveur est un serveur Virtuel
et le retour de la requête "SHOW dynamic_shared_memory_type" donne "posix"
Bonjour,
j'ai supprimé par erreur à travers une requête "Delete" des données d'une table.
Est-il possible de les récupérer?
Bonjour,
J'ai un soucis lorsque j’exécute une requête de sélection sur une table de ma base de données.
Ci-dessous l'erreur
could not open shared memory segment "/PostgreSQL.2113428277": Aucun fichier ou dossier de ce type
CONTEXT: parallel worker
Bien vouloir noter que cette table est volumineuses et compte prês de 50 000 enregistrements.
Bonjour à tous,
je viens vous présenter un soucis que je rencontre sur le démarrage de mon serveur Postgresql.
J'ai parcouru le fichier "postgresql.log" et jai vu ces messages
2022-11-11 10:57:25 GMT [3728]: [1-1] user=[inconnu],db=[inconnu],app=[inconnu],client=127.0.0.1LOG: connexion reçue : hôte=127.0.0.1 port=43148
2022-11-11 10:57:25 GMT [3728]: [2-1] user=kmothers_ml1,db=vitbank_ml,app=[inconnu],client=127.0.0.1FATAL: le système de bases de données se lance
2022-11-11 10:57:25 GMT [2504]: [2-1] user=,db=,app=,client=LOG: numéro magique invalide 0000 dans le segment 00000001000007D10000003B, décalage 0
2022-11-11 10:57:25 GMT [2504]: [3-1] user=,db=,app=,client=LOG: enregistrement du point de vérification primaire invalide
2022-11-11 10:57:25 GMT [2504]: [4-1] user=,db=,app=,client=LOG: numéro magique invalide 0000 dans le segment 00000001000007D10000003B, décalage 0
2022-11-11 10:57:25 GMT [2504]: [5-1] user=,db=,app=,client=LOG: enregistrement du point de vérification secondaire invalide
2022-11-11 10:57:25 GMT [2504]: [6-1] user=,db=,app=,client=PANIC: n'a pas pu localiser un enregistrement d'un point de vérification valide
2022-11-11 10:57:25 GMT [2442]: [1-1] user=,db=,app=,client=LOG: processus de lancement (PID 2504) a été arrêté par le signal 6 : Aborted
2022-11-11 10:57:25 GMT [2442]: [2-1] user=,db=,app=,client=LOG: annulation du démarrage à cause d'un échec dans le processus de lancement
2022-11-11 10:57:25 GMT [2442]: [3-1] user=,db=,app=,client=LOG: le système de base de données est arrêté
J'ai vu sur des plateforme qu'il y ait des possibilité que la base soit corrompue, jai demandé à un collègue de sauvegarde le répertoire DATA en attendant.
Maintenant comment investiguer?
Merci infiniment Daniel
J'ai profité pour comprendre le principe des accès simultané et de comment cela est géré par POSTGRESQL.
Votre réponse m'a permis de solutionner mon problème
Avez-vous suivui le lien pointé par Daniel permettant de voir la connexion qui détient le verrou bloquant, et ainsi de résoudre la situation ?
Bonsoir Admin,
je viens de finir les actions après parcours du lien.
Effectivement mon problème est reolu
Bonjour dverite,
effectivement j'ai vérifié à travers pg_stat_activity l'etat de la session de truncate.
La colonne "wait_event_type" a pour valeur "relation" et la colonne "wait_event" a pour valeur "Lock"
J'ai constaté que ma base de données a largement pris du volume. Dans mes investigations j'ai identifiée la table concernée qui posait problème.
J'ai exécuté une requête DELETE pour ne garder que les lignes de l'année en cours. Cette action a pris toute une nuit (près de 8h). J'ai pu garder 420 000 enregistrement à la suite de cette action. J'ai regardé la taille après cette action elle est à 227 Go. Depuis, plus rien, aucune action de maintenance (VACUUM , REINDEX, TRUNCATE) n'aboutit. Toutes les requêtes de tronquage , de suppression, de réindexation sur cette table rentrent dans une boucle interminable. j’arrête même sans que l'action se termine
J'ai récupéré le "relfilnode" de la table dans la table "pg_class" et quand j'ai vérifié dans le répertoire physique de la Base de données j'ai vu 227 fichiers de 1 Go chacun liés à cette table.
Je voudrais réinitialiser cette table de sorte à libérer l'espace sur le disque. Par quel moyen puis-je le faire?
Bonjour à tous,
Par inadvertance j'ai executé un script qui a tronqué des données d'une table.
C'est assez grave car c'est une table assez important de mon système.
Est-ce que Postgresql me donne la possibilité de restaurer les données de cette table tronquée.
Pages : 1
