Windows utilise une convention différente des systèmes Unix pour nommer ses locales, et notamment sur le fait que l'encodage (UTF8) ne fait pas partie du nom.

Essayez plutôt

create collation fr_FR ( LOCALE = 'French_France.1252')

Le port indiqué par quoi? Pourquoi s'intéresser au port 53, qui est le port du service DNS?

En fait les éléments de la discussion laissent penser que postgres ne se lance pas. Par exemple le résultat de ps:
quand ps aux|grep postgre ne trouve que le processus grep, ça veut dire que postgres ne tourne pas ou au mieux qu'on ne regarde pas au bon endroit. Dans le cas d'une recherche de problème, il ne faut pas faire comme si c'était positif et passer à la suite.

Il faudrait regarder les logs dans /var/log/postgresql ou équivalent suivant la distrib. Si postgres s'arrive pas à se lancer ça doit être écrit dedans avec les messages d'erreur correspondant.

Il faut savoir si le besoin est un pivot avec colonnes statiques ou dynamiques.

Si la liste des colonnes est statique, la fonction crosstab() de tablefunc peut faire l'affaire.

Si la liste des colonnes est dynamique (peut changer d'une exécution à l'autre) il faut générer dynamiquement la requête qui va afficher les résultats pivotés. Cette requête peut être un crosstab mais quand on en est à la générer, on peut aussi bien produire une requête indépendante:

 SELECT 
    autres colonnes,...
    (CASE WHEN colonne='la valeur1' THEN expression END) AS "la valeur1",
   ... etc pour toutes les valeurs possibles de la colonnes

ce résultat étant la structure de base d'un pivot.

C'est une option de sh. D'après man sh:

Les logs de connexion sont dans le même fichier que les autres logs. Les échecs de connexion devraient y être dans tous les cas. Pour voir toutes les connexions, y compris les succès, mettre

log_connections = on

dans le postgresql.conf, redémarrer le serveur, regarder les logs à ce moment là, faire la manip avec dolibarr, et comparer les logs entre juste avant et juste après.

L'erreur mentionnant pg_logdir_ls() vient du logiciel pgAdmin, elle n'a pas de lien direct avec le reste.

Pour moi ce message d'erreur de dolibarr est intéressant

  "La connexion ayant échoué, les paramètres du serveur ou du super utilisateur sont peut-être incorrects"

Il dit explicitement qu'il veut se connecter en superutilisateur mais vous ne dites pas que le dolibarrowner que vous avez créé est superutilisateur.

Si la procédure d'install de dolibarr veut être superutilisateur c'est peut-être parce que c'est elle qui est censée créer l'utilisateur et la base. Parce que si ce n'est pas pour ça, ce serait pour quelle autre raison?

La partie postgresql du log est ici:

J'ai ajouté des sauts de lignes car ce sont deux erreurs bien distinctes.

La première erreur "Connection refused" vient de la couche réseau. Vraisemblablement le tunnel est en IPv4 seulement mais localhost se résoud en plusieurs adresses: IPv6 (::1) et IPv4 (127.0.0.1) et il commence par essayer l'IPv6 (=>échec) puis l'IPv4 (=>succès au niveau réseau en tout cas).

Une fois que la connexion est établie au niveau réseau vers 127.0.0.1:4444 il parle effectivement à un serveur PostgreSQL en face, qui produit la 2eme erreur:

FATAL:  password authentication failed for user "MY_USER"

qui est une erreur classique de login invalide ou mot de passe invalide.

Pour le DISTINCT ON, non ma remarque n'est pas pour la sous-requête mais pour la requête dans son intégralité.
C'est-à-dire que vu génériquement au lieu de faire:

SELECT colonnes FROM table t1 where date=(select max(date) from table t2 where t1.id = t2.id) ;

DISTINCT ON permet d'écrire

SELECT distinct on (id) colonnes FROM table ORDER BY id, date DESC;

qui traduit la même idée de manière plus directe, c'est-à-dire pour chaque id, ne garder que la date la plus récente.

cf https://docs.postgresql.fr/10/sql-select.html section "DISTINCT Clause"

On pourrait expliquer pourquoi c'est lent en regardant le EXPLAIN ANALYZE de la requête.

Pour moi le CREATE USER MAPPING ne donne pas de droit implicite sur les tables distantes créées plus tard. Les droits sur les tables distantes sont gérées exactement comme pour tables locales: le possesseur a tous les droits et les autres doivent acquérir via un GRANT, plus ou moins direct.

Sur la question de l'utilisateur admin, dans postgres, je comprends ça comme admin=SUPERUSER.  postgres n'est pas un utilisateur spécial en-dehors d'être SUPERUSER et tout utilisateur SUPERUSER peut faire la même chose que lui. Pour un SUPERUSER, grosso-modo tous les tests de droits d'accès sont court-circuités. Il pourra toujours faire n'importe quoi sur n'importe quelle table.

Le problème est de corréler la valeur aléatoire et la date, de façon à ce que le moteur ne sorte pas une seule valeur pour toutes les dates, alors qu'il n'y a aucune corrélation "naturelle". Il y a sûrement plein de méthodes, en voici une qui me vient avec LATERAL:

select d.x,r.a
 from generate_series(timestamp '2018-01-01', '2018-02-08', '1 day') as d(x)
  join lateral (VALUES ('toto'),('titi'),('tata') ORDER BY random(),d.x limit 1) as r(a)
    on true;

Le fait d'ajouter d.x dans la clause de tri introduit une dépendance artificielle entre la 1ere et la 2nde colonne qui force postgres à recalculer la 2nde colonne à chaque ligne.

Le JOIN LATERAL est une nouveauté de la 9.3 qui justement permet d'exprimer qu'un résultat à gauche du JOIN doit être réinjecté à droite.

Il faut aussi se demander si c'est utile de faire un vacuumdb scripté en cron.

Ce type de script était utile et recommandé avant qu'autovacuum soit intégré, vers la version 8.0 ou 8.1, il y a plus de quinze ans, mais c'est censé être obsolète depuis.

Si vous n'avez pas une raison précise de faire ça, essayez de le supprimer. Et autovacuum peut être paramétré pour le rendre plus ou moins agressif si nécessaire.

Avec un nombre de valeurs impaires, je m'attendrais à ce que la médiane soit exactement un élément de la liste.

10.94 doit correspondre à 10.938 avec un arrondi à 2 décimales, mais 10.87 correspondrait à quoi?