Si vous voulez juste copier les colonnes valeur1, valeur2, ... valeur9 pour la valeur de clé 3 vers la ligne de valeur de clé2, une solution pourrait être de ce style :

update testtable
set (val1, val2)  = (t2.val1, t2.val2)
     from testtable t2
    where t2.cle = 3 and testtable.cle = 2

En fait Marc, la question a été posée à 2 endroits par geosic, dont une nouvelle discussion : http://forums.postgresql.fr/viewtopic.php?id=2100

Pour compléter le commentaire de Gleu : ce que vous cherchez à faire n'est pas clair : pourquoi les 2 installations partageraient-elles le même dossier de base de données? Si votre but est que le 2ème serveur prenne le relais du 1er en cas de défaillance, c'est plutôt contradictoire même. Si vous avez un problème sur le disque, alors à quoi sert le 2ème "nœud"?
En effet, vous précisez que vous voulez en cas de défaillance, que le 2ème nœud prenne le relais. Cela ressemble à un besoin de réplication (ce que propose Gleu), et de bascule automatique (à ma connaissance, il faut un autre outil, PostgreSQL ne fait pas cela, ni Slony : http://www.slony.fr/documentation/slonyintro.html#introduction )
Vous devriez peut-être préciser (ou vous faire préciser si ce n'est pas vous le demandeur) quel est le besoin réel?

Quant à la demande d'aide, si vous avez besoin de formation et/ou de l'aide d'un professionnel, allez sur la liste ici : 
http://www.postgresql.org/support/professional_support/
Vous pouvez également voir la liste européenne, la plupart des entreprises française ayant des clients également au Maroc.

Mais pourquoi donc supprimer les trous? En avez-vous réellement besoin?
Comme dit rjuju, dans 99% des cas, on laisse la séquence faire son travail (elle garantit l'unicité, pas l'absence de trous)
Si on a vraiment besoin de ne pas avoir de trous, on fait autrement (mais attention alors à bien gérer la concurrence, et ne pas oublier la possibilité d'un rollback)

Si tes utilisateurs ont Open Office ou Libre Office, il y a peut-être moyen de créér des rapports OpenOffice Base (ou Libre Office). C'est plus simple, mais du coup moins adaptable qu'un site web maison.

Bon, tout d'abord il ne me semble pas qu'il manque des index dans les tables.

Ah, ça pourrait avoir un lien. notamment à cause de mauvaises statistiques.
http://docs.postgresqlfr.org/9.1/sql-analyze.html
En un an, je suppose que les données ont pas mal évolué?

Je suis surtout développeur en fait, mais avant de chercher un problème de paramétrage, de système (ce qui sort de mon domaine de compétence, surtout avec le contexte particulier de votre serveur), j'essayais d'éliminer des causes de développement (ce qui est le cas de la grande majorité des problèmes rencontrés).
Après, d'autres personnes vraiment expérimentées en administration vous aideront certainement si ce n'est pas cela.

Ceci dit, si toutes vos petites bases ont des soucis, c'est soit :
qu'une grande partie des développements ont des problèmes − cela arrive − ( je mets dans le développement la structure des données)
soit des problèmes d'administration

ou un peu de chaque...

Que veux-tu dire par : "Je ne suis pas persuadé quant à moi qu'un des deux cas doive forcément être plus efficace que l'autre".
J'aurai pensé au contraire que comme le 2ème est une sorte de "meta-schéma" c'était forcément moins efficace. C'est le sens de la 2ème partie de ta phrase?

Si vous n'avez pas compris, alors ne repose pas la même question. Cherchez... Ou demandez plutôt des exemples, de la doc...
Apparemment vous n'avez pas du tout compris comment on mettait à jour la table à partir du trigger. Je viens de relire la doc de Postgresql, elle est claire (notamment le 1er exemple)
http://docs.postgresql.fr/9.1/plpgsql-trigger.html
Lisez-la et revenez poser des questions sur ce que vous ne comprenez pas, ce sera plus constructif.
Si vous avez eu un cours Oracle, c'est le même principe de mise à jour.

ordre_sql :='COPY (SELECT * FROM nom_table WHERE numero = num_id  LIMIT 1)
                 TO D:/EasyPHP-5.3.8.1/tmp/RI_AXI_0_'||numero||'.txt';

Je ne vois pas comment le TO... pourrait être interprété? Il n'y a pas de variable numero.
Ce n'est pas plutôt num_id qu'il faudrait mettre à la place de numero?

                 TO D:/EasyPHP-5.3.8.1/tmp/RI_AXI_0_'||num_id||'.txt';

(supprimé car faux, ça m'apprendra à faire 2 choses en même temps   )

Cela signifie qu'il a été fait un COMMIT ou un ROLLBACK inutile.
Cela dépend donc de l'application (il faudrait voir comment l'application gère les transactions).

Le log_line_prefix gère juste le préfixe, c'est plutôt du côté de log_min_messages que vous devriez regarder si vous voulez ne pas voir les warnings.
http://docs.postgresqlfr.org/9.1/runtim … gging.html

Oui, ma remarque était purement pratique : quand on tombe dans ce genre de problème, comment faire pour que cela impacte le moins possible le code? (dans le cas où on ne supporte qu'un moteur)

En pratique, pour ofthestreet qui doit gérer plusieurs moteurs dans le même code, si j'ai bien compris, je ferais plutôt la conversion booléen <-> entiers dans le code de l'application et je gèrerais tout avec des INTEGER en base. C'est pas très beau, mais au moins ce sera le même code pour tous les moteurs.