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:

sudo -u postgres pg_dump --format c -d mabd > /home/user/backup/`date +%Y%m%d`_mabd.backup

==>

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:

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...