Bonjour à tous,

Je ne suis pas encore une brutasse absolue sous postgreSQL et rencontre un écueil que je n'arrive pas à résoudre seule. C'est pas faute d'avoir essayé...

Je dois migrer une application et sa base de données d'un serveur à un autre. Après un pg_dump, je rebalance ma BD avec un pg_restore:
Code :Sélectionner tout -Visualiser dans une fenêtre à part
sudo -u postgres pg_dump --format c -d mabd > /home/user/backup/`date +%Y%m%d`_mabd.backup

==>
Code :Sélectionner tout -Visualiser dans une fenêtre à part
1
2
sudo su postgres
pg_restore -d mabd /home/user/backup/20190409_mabd.backup


Quand je fais le pg_dump/restore depuis une version light de la BD (ma version crash-test sur une machine virtuelle), ça passe les doigts dans le nez.
Quand je le fais depuis ma BD en production (donc un pg_dump de 4... Go!!), ça coince sur une table trèèèès lourde:
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 5867; 2606 41976 CONSTRAINT dem_vector pk_dem_vector utilisateurxx
pg_restore: [archiver (db)] could not execute query: ERROR: could not extend file "base/202593/224563": wrote only 4096 of 8192 bytes at block 89651
HINT: Check free disk space.
Command was: ALTER TABLE ONLY ref_geo.dem_vector
ADD CONSTRAINT pk_dem_vector PRIMARY KEY (gid);
Il semble quand même aller jusqu'au bout mais je n'ai pas de visibilité s'il y a eu des données "abandonnées" en route.

Côté serveur, j'ai 18Go/64 libres. Pour la mémoire "hôte", j'ai 8 Go. Je dois quand même avoir assez d'espace disque pour traiter un gros fichier, non?
Dans le postgresql.conf, j'ai essayé de modifier les paramètres effective_cache_size (ouvert à 4Gb) et work_mem (poussé à 10Mb) mais j'ai toujours le même message (j'ai lancé un service postgresql restart après avoir modifié le postgresql.conf).

Y a-t-il un moyen de contourner le bug?
Faut-il que j'opte pour un autre format d'export/import?
A noter qu'en plus des nombreuses tables, cette base contient des contraintes, des triggers, des vues matérialisées... Bref, la restaurer table par table puis contraintes, triggers, etc, ce serait l'enfer...