Si vous faites ça il faut aussi réindexer tous les index qui utilisent cette collation dans toutes les bases de cette machine. Car ils sont tous invalides après ça.

Personnellement je suggérerais d'étudier une variante où on crée une nouvelle collation dans Linux sans toucher à l'existant. Suivi d'un CREATE COLLATION dans PostgreSQL.

Je suppose que vous vouliez dire de 1,3 To à 300 Go.

Quoiqu'il en soit effectivement les options pour dégonfler pg_largeobject sont limitées.
Par exemple il y a eu cette question  sur  la liste -general en anglais, sans alternative trouvée au VACUUM FULL.

Admettons que vacuumlo ait fait son travail, c.a.d appeler lo_unlink() avec tous les OIDs non référencés.
Pour se faire une idée, quel est après ça l'état des lieux en termes de :

- combien d'objets restent:  SELECT count(*) FROM pg_largeobject_metadata

- quelle taille utile ils font:  SELECT sum(octet_length(data)) FROM pg_largeobject

- quelle taille disque fait la table: SELECT pg_relation_size('pg_largeobject');

- quelle taille pour la table+son index: SELECT pg_total_relation_size('pg_largeobject')

Sinon pg_largeobject possède bien une clef primaire sur la valeur composite (loid, pageno), mais peut-être que ça ne convient
pas à pg_repack?

\d+ pg_largeobject
                  Table "pg_catalog.pg_largeobject"
 Column |  Type   | Modifiers | Storage  | Stats target | Description 
--------+---------+-----------+----------+--------------+-------------
 loid   | oid     | not null  | plain    |              | 
 pageno | integer | not null  | plain    |              | 
 data   | bytea   | not null  | extended |              | 
Indexes:
    "pg_largeobject_loid_pn_index" UNIQUE, btree (loid, pageno)

C'est peut-être une incompatibilité de version ou d'options de compilation entre ce postgres et ce postgis.

Quelles sont les versions des deux et de quelles sources viennent-ils? Compilation perso? Packages? Quelle(s) source(s) de packages?

Ce qu'on peut dire sur le log ci-dessus est que "signal 6: Aborted" est dû au programme lui-même qui appelle abort(). Que ce soit postgresql ou postgis qui le fait, difficile à dire. On peut aller plus loin avec un fichier core et/ou une trace:

https://wiki.postgresql.org/wiki/Genera … QL_backend

Ce chemin /etc/postgresql/9.5/main ressemble à un répertoire contenant des fichiers configurations dans une structure à la Debian, et pas des données.

Les données seraient plutôt dans /var/lib/postgresql/9.5/main

Côté procédure, le remplacement pur et simple de PGDATA par un backup à froid ou un snapshot cohérent fonctionne généralement, si le serveur est identique à celui en fonction lors du backup.

Si on parle de CREATE TABLESPACE, non ce n'est pas possible parce que la liste et les structures des tables sont dans d'autres tables (du schéma pg_catalog) et il n'y  a pas d'auto-découverte possible des tables et autres objets dans un tablespace pris isolément.

Par ailleurs, quand l'instance d'avant a été arrêtée, les données dans ce tablespace en étaient à un certain avancement de transaction   qui est lié à cette instance et ne correspond plus à rien dans la nouvelle instance.

En clair un tablespace pris isolément est inutilisable, autant que des fichiers de données qu'on aurait pris directement de $PGDATA.

Cette ligne suppose qu'il y a une base existante appelée icingaweb2.
Admettons que cette base appartienne à un utilisateur icinga et que les objets contenus appartiennent aussi à un utilisateur icinga.
Cet utilisateur aura été créé par CREATE USER.

Si le web est configuré pour se connecter avec l'utilisateur icinga à cette base via localhost et avec le mot de passe choisi à la création de l'utilisateur, le GRANT ci-dessus n'a pas besoin d'équivalent, parce que:

- l'utilisateur existe déjà
- il a déjà tous les droits sur tous les objets de sa propre base.
- un pg_hba.conf normal donne déjà le droit de se connecter avec un mot de passe via localhost.

GRANT lecture_production, report_production to "Production3";

L'erreur portant sur IPv6 indique que c'est bien une connection IPv6 faite par le client. Mais ce n'est pas très surprenant, pour beaucoup de systèmes maintenant localhost est alias de 127.0.0.1 et aussi de ::1. Le plus simple est d'utiliser explicitement 127.0.0.1 pour forcer IPv4 si nécessaire.

Pour le mot de passe, je m'attendrais à ce que soit le même que celui demandé à l'installation de PostgreSQL.

Reste que pgAdmin ne sait apparemment pas se débrouiller avec un message d'erreur non utf-8 au moment de l'établissement de la connexion, ça a l'air d'être un bug qui mériterait de leur être signalé s'il n'est pas déjà enregistré dans leur outil:
https://redmine.postgresql.org/projects/pgadmin4

pgAdmin et le serveur PostgreSQL sont deux logiciels séparés qui communiquent par réseau. Même s'ils sont installés sur la même machine.

Quand on "crée un serveur" sous pgAdmin, on indique où se trouve PostgreSQL et comment le joindre, et aussitôt il chercher à s'y connecter, et c'est là apparemment que l'erreur survient.

Biensûr tout le monde n'a pas cette erreur sinon les développeurs n'auraient même pas diffusé pgAdmin dans cet état, il y a une variabilité lié à l'environnement là-dessous. Vu que l'erreur concerne l'encodage d'un E accentué, ça oriente clairement vers une histoire d'environnement francophone versus anglophone.

PostgreSQL a un fichier de configuration qui s'appelle postgresql.conf et je suggère d'aller vérifier et changer le paramètre lc_messages dans ce fichier.

Par ailleurs il a des fichiers de log qui consignent les erreurs qui surviennent et je suggère aussi de regarder s'ils mentionnent qq chose au moment de l'erreur.

L'emplacement des logs est spécifié dans postgresql.conf, ça peut atterrir aussi dans le journal de windows lisible avec l'observateur d'évènement de windows.

Je n'ai pas d'expérience personnelle là dessus mais ceux qui ont eu le même message d'erreur ont l'air de dire que:

- il faut que java soit dans le $PATH

- il faut que pljava.so (et peut-être pljava.jar s'il y en a un) soit dans le répertoire $libdir de postgresql, au même endroit que les autres extensions (trouvable par la commande shell "pg_config --pkglibdir" si nécessaire)

LD_LIBRARY_PATH est une liste de répertoires, pas une liste de fichiers.

Si libjvm.so est dans
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-2.b11.el7_3.x86_64/jre/lib/amd64/server
c'est cette valeur qu'il faut mettre dans LD_LIBRARY_PATH

Si ça ne fonctionne toujours pas, vérifier aussi que cette variable est bien dans l'environnement du serveur postgres quand il démarre.

S'il n'y a pas de trigger, ce n'est donc pas ça.

Mais ce qu'il faut comprendre par rapport à l'erreur qui mentionne "LINE 3" c'est que cette ligne 3 ne se réfère par à une ligne de la table, mais à la ligne d'un code SQL qui est appelé plus ou moins directement par la mise à jour que vous faites via l'interface PgAdmin4.

Pour y voir plus clair, il serait utile d'examiner ce code SQL quand l'erreur se produit. Par défaut le paramètre log_statement dit au serveur d'écrire dans son log les requêtes en erreur, donc il y a de bonnes chances que l'information soit dans le log du serveur.