Stanley : regarde le logiciel de conversion ogr2ogr :

http://www.gdal.org/ogr2ogr.html

Je vois pas ce que tu appeles « la somme des colonnes "size" ».
De ce que je comprends de ton énoncé, ça donne

SELECT *
FROM fichiers f
WHERE f.size <= TAILLE_MAX
ORDER BY f.date
LIMIT x

Un exemple concret de résultat attendu serait utile

pgAdmin ne peut rien pour toi dans ce cas là....

Si tu as fais une copie du répertoire data avant de réinstaller PostgreSQL alors la procédure est la suivante :

1/ Arrêter le serveur PostgreSQL
2/ Renommer le répertoire data actuel
3/ Remettre la copie à la place du répertoire data
4/ Relancer PostgreSQL

Attention cela ne peut fonctionner que si les conditions suivantes sont respectées :

a/ La copie des fichiers du répertoire data a été faite alors que le serveur était arrêté
b/ La nouvelle version de PostgreSQL installé est de la même version majeure que la première

Merci !

Est-ce que la base "Qantify" existe ? Au passage c'est une très très très mauvause idée de mettre des majuscules dans les noms de bases et de tables.

Merci pour cette initiative !

Peux-tu présenter un peu plus ton projet ? Est-ce un fork de sugarCRM ou un plugin ? Le paquet fait 36Mo ça me parait énorme....

Connais-tu vTiger ? Quelles différences entre ton projet et vTiger ?

As-tu prévu un moyen de migrer un base existante sous mysql vers PG ?

Le default_statistics_target = 1000 est un peu brutal. Cela signifie que lors d'un ANALYSE, PostgreSQL prend 1000 échantillons dans chaque colonne de chaque table.
Le plus souvent c'est inutile. Si vous voulez monter aussi haut, autant le faire sur les colonnes qui vous semblent les plus pertinentes :

ALTER  COLUMN  colonne SET STATISTICS 1000;

Tu décris deux problèmes différents :

A/ Le serveur n'écoutait pas sur l'adresse 127.0.0.1 et le port 5432. Il peut y avoir plusieurs raisons à cela. Peut-être que le serveur PostgreSQL était éteint. Peut-être que la variable listen_adresses étaient mal configurée.  Peut-être qu'un pare-feu sur la machine bloque les connexions.

B/ Pour sauvegarder une base de donnée, il faut utiliser la comande pg_dump. Il ne faut JAMAIS copié, ni déplacé un des sous-répertoires qui se trouvent dans le dossier base. Il est certain que si vous copier le dossier  16547 sur votre nouvelle installation le serveur PostgreSQL refusera de démarrer et vous retomberez sur le problème A.

Je ne suis pas sur de comprendre la question.
Si le but est de se protéger contre une mauvaise manip, il suffit de créer un role qui ne dispose que des droits en lecture.

Apparement la base restaurée est en UTF8 tandis que la sauvegarde ne l'est pas.

Il faut refaire un dump en UTF8 ou convertir le dump actuel

Ce n'est pas possible de manière automatique. Il faut créer le type SERIAL "à la main".

Par exemple, en imaginant que tu veux ajouter la colonne id dans la table t1 :

BEGIN;
CREATE SEQUENCE t1_id_seq;
ALTER TABLE t1 ADD COLUMN id INTEGER;
UPDATE t1 SET id = nextval('t1_id_seq'); 
ALTER TABLE t1 ALTER COLUMN id SET DEFAULT nextval('t1_id_seq');
ALTER TABLE t1 ALTER COLUMN id SET NOT NULL;
COMMIT;

Attention l'opération UPDATE peut être assez longue, suivant le volume de données dans la table t1.

C'est probablement une erreur de syntaxe.
Est-ce que tu peux nous donner la requête que tu essaies d'exécuter ?