PostgreSQL
La base de données la plus sophistiquée au monde.

Ouverture de session

Navigation

Contactez-nous

Administration du site :
"equipe chez postgresqlfr point org"

Contact presse :
"fr chez postgresql point org"

Contact association :
"bureau chez postgresqlfr point org"

Questions PostgreSQL :
 IRC :
  serveur irc.freenode.net
  canal #postgresqlfr

Recherche

Accéder aux archives

« Octobre 2008  
Lun Mar Mer Jeu Ven Sam Dim
  2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  

Syndication

Flux XML

Sondage

Quelle est la version de PostgreSQL la plus répandue sur vos serveurs ?
8.3
10%
8.2
42%
8.1
40%
8.0
2%
7.4
6%
7.3 ou antérieure
0%
Nombre de votes: 48

Problème avec pg_dump

Technique - interfaces | Problème avec pg_dump

Par seb042 le 30/07/2008 - 14:23

Bonjour,

J'ai un soucis avec pg_dump sur une de mes bases. Voici le message d'erreur :

pg_dump: Dumping the contents of table "wct_binary" failed: PQgetCopyData() failed.
pg_dump: Error message from server: lost synchronization with server: got message type "d", length 658306580
pg_dump: The command was: COPY public.wct_binary (binary_id, data) TO stdout;
pg_dump: *** aborted because of error

La commande utilisée est la suivante : pg_dump -Fc -b mabase -f fichierdump

La table qui bloque est une table ayant deux champs : un entier (id) et un bytea (blob qui stocke des fichiers).

J'ai essayé pas mal de choses : vacuum, reindex, drop et recréation d'index ... j'ai pu faire un COPY de la table sur disque et la recharger après un drop mais pg_dump ne passe toujours pas. J'ai également essayer plusieurs versions de pg_dump (8.0.14, 8.1.3, 8.3.3).

Infos techniques :
version base = 80.14
version OS = liunx ES 4up4

Quelqu'un aurait il une idée?

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur "Sauvegarder les paramètres" pour activer vos changements.

Bonsoir version OS = liunx E

bustaf/ = 31 Juillet, 2008 - 03:05

Bonsoir
version OS = liunx ES 4up4 ???
LINUX ES 4.4 REDHAT ???

Le -b affecte le blob comme une donnée std
Je pense que la taille formatée ainsi est trop importante
1 Essayez -Z9 pour monter le taux de compression au maximun.
2 Essayez a la place du (-f fichier) ( > fichier) pour un flux stdout directement redirigé non tributaire des indices buffer de pg_dump ???.(Pas certain que cela change quelque chose ???? mais il faut essayer...)
4 Si le (>) ne marche pas tapez au shell ulimit -a (pipe size et stack size) pour voir vos valeurs et les elever si possible..
Bon courage....
Cordialement
NB
Utiliser la Version 8.2.5 pour éviter un autre problème potentiel liés UTF8 à la restore si vous avez du binaire dans la base ... (imperatif... initdb -E=LATIN1 ....)


OS = Red Hat 4 update 4 J'

seb042/ = 31 Juillet, 2008 - 16:18

OS = Red Hat 4 update 4

J'ai essayé la solution proposé, même problème. J'ai l'impression que pg_dump butte sur un enregistrement (il s'arrête à 3.8 Go alors que le fichier final fait environ 6.3 Go pour cette table).


Problème de taile lors du fecth ?

seb042/ = 4 Août, 2008 - 09:24

A priori pg_dump n'arrive pas à faire un fetch des 100 enregistrements suivants après un enregistrement en particulier. Y'a t il un moyen de lui faire faire un fecth plus petit ?


© PostgreSQLFr, tous droits réservés.
Site déclaré à la CNIL sous le numéro 1074678, conformément à la Loi en vigueur.