C'est aussi comme ça que je le comprends, mais si on suppose que message.id est une clef primaire,
un UPDATE message SET ... WHERE id IN (...) RETURNING *
qui retourne plusieurs lignes, ça laisse penser que la sous-requête du IN (...) retourne plusieurs valeurs.

Ceci dit je me demande si un index corrompu sur message.id pourrait provoquer ce phénomène bizarre indépendamment du détail de ce qu'il y a dans la clause IN.

Effectivement si le CSV est généré sans considérer le guillemet comme un caractère spécial, ça peut produire ce genre de problème. Et c'est assez plausible parce que pas mal de générateurs sont baclés en 3 lignes de code sans se soucier de cette règle ou des champs multilignes.

Pour un calcul de médiane tout fait en postgresql moderne, on peut utiliser percentile_cont ou percentile_disc.
Voir https://forums.postgresql.fr/viewtopic.php?id=4218

Votre backup a l'air parfait, c'est la restauration qui doit poser problème. Au vu des tables vous utilisez postgis, donc le problème le plus plausible est qu'il ne soit installé pas sur l'instance cible. Dans ce cas les tables qui en dépendent ne sont pas créés, en produisant des erreurs affichées par la sortie écran de la restauration ainsi que dans les logs du serveur.

Si postgis est installé sur la cible, il faut vérifier quelle version par rapport à la base d'origine et s'il y a des indications de migration à suivre dans la doc de postgis par rapport aux sauts de versions.

Pour le https ton site https://rjuju.github.io/ serait un contre-exemple, parce qu'il est bien pris en compte.

Peut-être que ce sont les sites qui ont un certificat gratuit LetsEncrypt, si la base des autorités de certification du côté de l'agrégateur n'a pas été mise à jour depuis un moment .

Ou peut-être une incompatibilité de version TLS entre l'agrégateur et les serveurs https des blogs.

Non c'est bien ça

Il y a deux situations très différentes suivant qu'on place le code de gestion d'erreur côté client ou côté serveur ou un mix des deux.

Côté client, on suppose que vous pouvez ouvrir et maintenir deux connexions en permanence. Par exemple si votre appli est en php, vous allez avoir
  $db1 = pg_connect($connect_string);
et
  $db2 = pg_connect($connect_string);

Les traitements sont lancés avec pg_exec($db1, "BEGIN"); pg_exec($db1, "INSERT.. etc..");
et les logs avec pg_exec($db2, "INSERT INTO log... etc..");

Le fait que la session $db1 soit dans une transaction en échec n'empêchera pas du tout d'insérer via $db2.
Ca suppose juste d'avoir une interface client PG qui soit capable d'avoir plusieurs connexions simultanément; la plupart permettent ça.

L'exemple du premier message de la discussion laisse supposer qu'il y a un besoin d'annuler une transaction suite à l'impossibilité de déplacer un fichier côté client:

Pour ce besoin, le module dblink n'est pas nécessaire. dblink devient nécessaire si vous *voulez* logger les erreurs dans une table dans du code serveur des clauses EXCEPTION en plpgsql. Pour cette stratégie il y a encore deux sous-choix possibles:
1. ne pas remonter l'erreur au client et considérer qu'elle est "gérée"  après l'avoir loggé l'erreur avec dblink (mauvaise idée  (*) mais certains préfèrent procéder comme ça).
2. garder la transaction en échec, et remonter l'erreur au client (=faire un RAISE en plpgsql depuis le bloc d'exception, cf https://www.postgresql.org/docs/current … ages.html)

(*) je n'ai pas de lien Postgres sous la main mais le problème est similaire avec Oracle et il y a de bonnes explications sur le mésusage de la clause WHEN OTHERS avec Oracle ici: http://www.orafaq.com/wiki/WHEN_OTHERS

Le rôle peut servir à gérer les utilisateurs par groupe. On assigne un même rôle à un ensemble d'utilisateurs avec GRANT rolename TO username1,username2,... et ensuite on fait GRANT ou REVOKE de certains droits sur le rôle au lieu de spécifier individuellement les utilisateurs.
C'est pour cette raison que le rôle n'a pas par défaut le droit de se connecter.

Dans les versions anciennes de PostgreSQL, la notion de groupe d'utilisateurs était plus distincte, il fallait faire CREATE GROUP pour faire des groupes d'utilisateurs. Puis les groupes et les utilisateurs ont été unifiés avec le concept de rôle. Maintenant CREATE GROUP et CREATE USER existent toujours par compatibilité, mais ce sont juste des quasi-synonymes de CREATE ROLE.

La méthode du dblink est utilisable dans le cas où il appelé dans une clause EXCEPTION d'un bloc plpgsql. Un tel bloc est soit dans un bloc de code anonyme (DO...<code> LANGUAGE plpgsql) soit dans une fonction.

Ici il semble que ce ne soit pas le cas, c'est-à-dire que les instructions DELETE sont envoyés individuellement par le client et que la logique IF erreur SQL est dans le client. Vous ne pouvez pas utiliser le SELECT dblink_exect() dans cette situation.

Mais vous pouvez (devez en fait) dès qu'il y a une erreur SQL, lancer un ROLLBACK pour annuler définitivement la transaction en cours et de ce fait vous n'aurez plus ces erreurs 25P02.

Une fois ceci fait, il est possible d'insérer l'entrée de log avec un simple INSERT sans besoin d'un dblink. Le point crucial est que ça ne se fait pas dans la même transaction que celle qui était en échec et que vous terminez en exécutant un ROLLBACK explicite.

Tant qu'à réécrire le SQL, voyez si concat() ne serait pas plus lisible. Avec concat() les NULL reviennent au même que les chaines vides au lieu d'avoir l'effet "absorbant" de NULL avec l'opérateur ||:

test=> select concat('abc', ',' , null, ',' , 'def');
  concat  
----------
 abc,,def

concat_ws() peut aussi être utile. C'est encore plus lisible parce qu'on n'a pas besoin de répéter le séparateur mais les NULL sont ignorés.

cf https://www.postgresql.org/docs/current … RING-OTHER

Il y a apgdiff par exemple: https://github.com/fordfrog/apgdiff qui travaille sur le résultat de pg_dump.
Je me souviens l'avoir utilisé avec succès.

On peut terminer des sessions avec pg_terminate_backend() qui prend en argument le PID de la session, mais une session ne pourra jamais faire un DROP database en étant elle-même connecté à cette base.

Si le but est de recréer la base entièrement, il est possible d'utiliser pg_dump -C -c (les 2) avec le format plain (donc pas de -Ft, laisser le format par défaut), et de jouer ça dans un psql connecté à une autre base. Par exemple la base nommée postgres. Exemple:

pg_dump -C -c mabase > dump-mabase.sql
psql -U postgres -d postgres -f dump-mabase.sql

Le dump va contenir des commandes du genre

DROP DATABASE mabase;
...
CREATE DATABASE mabase ...;
...
\connect mabase
...
puis les commandes de création des objets.

Mais il faut quand même que personne d'autre ne soit connecté à la base concernée quand on joue ce dump.

Le "CASE" interne semble faux parce que c'est un mélange des 2 formes

 CASE expression
   WHEN valeur1...THEN
   WHEN valeur2... THEN
   ...

et

 CASE
   WHEN condition1...  THEN valeur1
   WHEN condition2... THEN valeur1
 ...

Ces deux formes sont valides mais pas un mix des deux.

Indépendamment de ça vous pouvez certainement simplifier toute cette expression qui fait de multiples conversions date/chaîne de caractères pour calculer quelque chose qui sûrement pourrait s'obtenir de manière plus directe. Il faut voir aussi que coder en dur que le dernier jour de février est le 28 est faux à chaque année bissextile. Si le but est de trouver le dernier jour du mois en cours, il faudrait plutôt ajouter un mois et retrancher un jour avec interval '1 month' et interval '1 day'.