Vous n'êtes pas identifié(e).
bah oui vu que le mode archivage est activé des wall.ready sont présent
Bonjour,
Quelqu'un ici connait la commande pg_repack, j'aimerai avoir votre avis la dessus, avantage et inconvenient si c'est pas trop demandé.
https://pgxn.org/dist/pg_repack/doc/pg_ … stallation
Sinon si on fait un vacuum full avec cette commande est ce qu'il fait un reindex automatique après ?
Et est ce que donc de par cette commande on peut genre par exemple repatrier les index et tables existantes dans differentes tablespaces ?
Merci
Le processus du pid n'est plus trouvable. Et non pas de message PANIC.
En fait il existe un archive_command qui fait un rsync des wall mais je ne voit pas trop pourquoi si c'est du à cà ?
Salut,
Autour de celui-là existe pas de messages particulier, seulement les requêtes qu'il execute.
Sinon un exemple de message complet avec statement est :
2019-01-28 15:28:21 EAT [P:32755][S:5c4eefa9.7ff3][T:0][A:[unknown]] (postgres@[local]): [4-1] ERROR: could not stat file "pg_xlog/00000001000010D40000007E": No such file or directory
2019-01-28 15:28:21 EAT [P:32755][S:5c4eefa9.7ff3][T:0][A:[unknown]] (postgres@[local]): [5-1] STATEMENT:
2019-01-28 15:28:21 EAT [P:18381][S:5c4cba22.47cd][T:0][A:] (@): [1110-1] LOG: checkpoint complete: wrote 189547 buffers (2.6%); 0 transaction log file(s) added, 44 removed, 55 recycled; write=209.352 s, sync=0.094 s, total=209.701 s; sync files=502, longest=0.007 s, average=0.000 s; distance=1245287 kB, estimate=1245287 kB
Ce qui est bizarre c'est si tu dis qu'il en a besoin alors pourquoi les wall n'y sont plus. Et est ce que çà n'a pas influence avec la cohérence des transactions ?
Bonjour,
Nous utilisons PostgreSQL version 9.6 sur un OS linux centOS.
En regardant les log je vois des messages d'erreur : ERROR: could not stat file "pg_xlog/0000000100000AF800000094": No such file or directory
La base est en marche toujours, jusqu'ici il n'y a pas de problème mais ce message dans les logs me laisse penser, quels peuvent bien en être la cause de cet erreur ?
Auriez vous une réponse à cette question ?
Merci de votre attention
Oui existe bien les boucles et cruseurs avec postgresql. Il faudrait que tu crées une fonction selon ton besoin je pense:https://docs.postgresql.fr/8.3/plpgsql-control-structures.html
https://docs.postgresql.fr/8.4/plpgsql-cursors.html
Merci , en fin de compte on a restauré la table sans les lignes corrompues.
Merci à tous
Ca ne le fait pas il existe egalement d'autre id corrompu.
Je reprend : donc la seule solution est elle remplacer 00f4 évoquait plus haut ? Comment cré t-on ce fichier de remplacement ?
ah une autre idée faire un select en specifiant carrément la clé, donc de prendre le max(id) et select where id in (id_corrompu+1, id_corrompu+2, .. max(id)) je teste
Je ne peux même pas faire un select * from table_corrompu where id <> id_corrompu ni un select * from table_corrompu where id > id_corrompu.
Il doit faire un fullscan le truc et çà pête.
donc la seule solution est elle remplacer 00f4 évoquait plus haut ? Comment cré t-on ce fichier de remplacement ?
gleu > Merci pour ta réponse Guillaume.
En parcourant une à une les enregistrement de la table en question, on connait maintenant la ligne (1 champs dans cette ligne) qui pose problème.
Si je fais un DELETE de cette ligne et que je lance ensuite un VACUUM FULL sur la table, est ce que cela pourrait résoudre le problème ?
Petite rectification : postgresql 9.4.5 mais non 9.3.5
Personne une solution ?
Bonjour,
Je rencontre l'erreur suivant lors d'un dump sur une base de données particulière sur une table contenant des données binaire (ex: image, pdf,...) de type bytea.
Voici l'erreur en question:
pg_dump: Error message from server: ERROR: could not access status of transaction 256212738
DETAIL: Could not read from file "pg_clog/00F4" at offset 81920: Input/output error.
En regardant dans PGDATA/pg_clog le fichier 00F4 existe bien mais ne peut être lu.
Ex: un less pg_clog/00F4 renvoie l'erreur : read error
Environnement sous linux, version postgresql 9.3.5.
Sachant qu'il n'y a pas de sauvegarde dump à restaurer, est ce qu'il existe un moyen pour corriger le problème svp ?
Ok, merci beaucoup pour ces explications interessantes 
Merci de votre réponse rapide,
Donc si je comprends bien, seul pg_stat_all_indexes est à prendre en compte si on veux connaitre si un index est utilisé ou pas. Pouvez-vous confirmer svp?
Mais de coup quel est le vrai interet de pg_statio_all_indexes ?
Bonjour,
J'aimerai savoir quelle est exactement la différence entre les informations retournées par "pg_statio_all_indexes" et "pg_stat_all_indexes".
Notemment dans pg_stat_all_indexes on a:
idx_scan = Nombre de parcours d'index initiés par cet index
idx_tup_read = Nombre d'entrées d'index retournées par des parcours sur cet index
idx_tup_fetch = Nombre de lignes vivantes de la table rapportées par des simples parcours d'index utilisant cet index
Mais dans pg_statio_all_indexes, on a également:
idx_blks_read = Nombre de blocs disque lus pour cet index
idx_blks_hit = Nombre de tampons récupérés sur cet index
Le problème est: si je veux savoir si un index est utilisé ou pas, lequel des informations prendre en compte ? Car pour un index donné je vois par exemple :
idx_scan = 0, idx_tup_read = 0, idx_tup_fetch = 0 alors que idx_blks_read = 45357197, idx_blks_hit = 877656203
Peut être que le mode archivage est activé, alors qu'il n'y a pas paramètrage de copie des wal vers une autre destination. Du coup les fichier dans pg_xlog vont s'entasser.
Par curiosité, quelle est le réel intérêt de stoquer les données ainsi dans un champs json, la modèlisation ne pourrait être autrement ?
Bonjour,
Oui, çà me semble logique. Mais du coup pour le cas numero 2, comment l'application gère la limite de connexion ou c'est une question de programmation ?
Oui et non, en fait user1 ou user2 ici n'est pas un role de connexion ou role de groupe postgres. On a une table créée à part. On y conserve dans cette table les utilisateurs user1 et user2 et c'est cette table qui sera jouée par la suite pour rattacher des roles créés par rapport à l'application
Bonjour,
Serait il possible de limiter pour un utilisateur donné son nombre d'accès concurrente à la base postrgeSQL. En gros, gérer le nombre de connexion concurrente par session utilisateur.
Le paramètre max_connexion ne répond pas à cette besoin vu que ce paramètre englobe tous les sessions qui s'y connectent dans la base. Ce qu'on veut faire ici c'est de dire par exemple qu'un user 1 ne peut avoir que x nombre de connexion concurrente, user2 y nombre de connexion concurrente.
Existe il un moyen de faire çà ?
Merci d'avance
Si tu veux tracer les select et update sur une table spécifique, il te faudrait surement passer par un trigger assurant l'historique concernant cette table
une recompilation de postgres a résolu le problème merci
bah la version 1.3 elle marchait bien avant cela pourtant.
gleu > une version de pg 9.3 avec son pgdata et ses lib , puis une autre version pg9.4 avec ses lib mais cette fois ci avec 2 pdgata (1 par instance)
rjuju > pg_trgm 1.3 sur la 9.4
Est il possible d'effecteur une autre installation de postgresql mais ciblant le pgdata d'une instance dejà présente ?
