Dans pg_hba.conf vous pouvez ajouter la méthode CERT:

hostssl db            usr            192.168.0.1/16         cert 

Demander à PostgreSQL de prendre en compte cette modification avec:

pg_ctl reload

Et vérifier dans le log de PostgreSQL qu'il n'y a pas d'erreur (car s'il y a une erreur dans pg_hba.conf, pg_ctl ne dit rien):

2020-06-29 09:00:20.313 CEST [11349] LOG:  received SIGHUP, reloading configuration files

S'il y a une erreur vous avez des messages qui signifient que le modification de pg_hba.conf n'a pas été prise en compte:

2020-06-29 09:03:31.821 CEST [11349] LOG:  received SIGHUP, reloading configuration files
2020-06-29 09:03:31.822 CEST [11349] LOG:  invalid authentication method "clientcert=verify-ca"
2020-06-29 09:03:31.822 CEST [11349] CONTEXT:  line 83 of configuration file "/var/lib/pgsql/12/data/pg_hba.conf"
2020-06-29 09:03:31.822 CEST [11349] LOG:  pg_hba.conf was not reloaded

Dans ce cas PostgreSQL continue de fonctionner mais avec l'ancienne version de pg_hba.conf.

Si vos tests ne fonctionnent pas, précisez quels sont les certificats que vous avez installés côté client ainsi que les message d'erreur à la connexion (de préférence avec psql) et les messages d'erreur correspondants dans le log de PostgreSQL.

Oui c'est possible. Il y a au moins 2 méthodes: soit réinstaller PG mais en prenant garde de ne  P A S  relancer un initdb qui pourrait écraser le répertoire PGDATA  par défaut, soit copier le dossier PGDATA sur une autre machine dans un nouveau dossier où PG est installé.

Il faut en savoir plus, quelle est la version de PG utilisée,  quel est le système cible (version Windows, distribution Linux précise), quel est l'installateur précis qui a été utilisé (yum, rpm, apt ou installateur graphique).

La première chose à faire avant tout c'est de sauvegarder PGDATA dans l'état actuel.

Il faudrait donner un exemple précis avec le code SQL de la vue matérialisée et de ses dépendances.

Mais je ne connais pas de commande SQL dans PostgreSQL qui va dans ce sens: la commande ALTER MATERIALIZED VIEW ne permet essentiellement que de renommer des colonnes d'après: https://docs.postgresql.fr/12/sql-alter … dview.html.

Sur la page GitHub, certains semblent être arrivés à l'installer sur Windows soit directement (mais avec difficultés) soit en installant le package apt dans le système Linux de Windows:
https://github.com/dimitri/pgloader/issues/652

Sinon il existe toujours la possibilité d'avoir une machine virtuelle Linux sur Windows et d'y installer pgloader.

Ce fichier me semble correct. Si le service est bien démarré avec ce fichier au bon endroit, il devrait y avoir un log généré dans le répertoire pg_log.
Vérifiez qu'il n'y a pas d'erreur dans le journal des événements Windows au moment du démarrage du service.

Réinstaller PostgreSQL est risqué car vous risquez de perdre vos données dans PGDATA: sans sauvegarde c'est risqué.

Les fichiers pga_hba.conf et postgresql.conf sont livrés avec beaucoup de commentaires: essayez de copier ces fichiers dans

c:\Program Files\PostgreSQL\9.0\data

, de redémarrer le service PostgreSQL et de vérifier s'il y a log généré.

Même si la commande "net start" ne donne rien, le service Windows existe d'après la commande "sc query".

Les fichiers pg_hba.conf et postgresql.conf doivent impérativement être dans dans votre cas dans "PGDATA" càd dans

c:\Program Files\PostgreSQL\9.0\data

Essayez de déplacer ces 2 fichiers à cet endroit et de démarrer le service Windows de l'instance PG avec:

sc start postgresql-x64-9.0

Est-ce qu'il y  a des erreurs ?
Est-ce qu'il y a maintenant un log dans pg_log et si oui quel est son contenu ?

Pour installer une ancienne (ou une nouvelle) version de Postgres sur Linux, il est toujours possible de l'installer à partir du code source: https://docs.postgresql.fr/9.3/installation.html.
Sinon il est possible d'utiliser l'exécutable pg_dump 12 pour exporter la base source en version 9.3 et l'exécutable pg_restore 12 pour importer  dans la base cible en version 12.

Exemple pour passer de 9.3 à 11: il faut bien utiliser les exécutables pg_dump et pg_restore de la version 11.

Je trouve la formulation de la documentation officielle assez ambigüe et qu'elle manque vraiment d'exemple sur ce point spécifique de changement de version:

Parce que pg_dump est utilisé pour transférer des données vers des nouvelles versions de PostgreSQL™, la sortie de pg_dump devra pouvoir se charger dans les versions du serveur PostgreSQL™ plus récentes que la version de pg_dump. pg_dump peut aussi extraire des données de serveurs PostgreSQL™ plus anciens que sa propre version. (À l'heure actuelle, les versions de serveurs supportées vont jusqu'à la 8.0.) Toutefois, pg_dump ne peut pas réaliser d'extraction de serveurs PostgreSQL™ plus récents que sa propre version majeure ; il refusera même d'essayer, plutôt que de risquer de fournir une extraction invalide. Par ailleurs, il n'est pas garanti que la sortie de pg_dump puisse être chargée dans un serveur d'une version majeure plus ancienne  -- pas même si l'extraction a été faite à partir d'un serveur dans cette version. Charger un fichier d'extraction dans un serveur de version plus ancienne pourra requérir une édition manuelle du fichier pour supprimer les syntaxe incomprises de l'ancien serveur. L'utilisation de l'option --quote-all-identifiers est recommendée lors de l'utilisation avec des versions différentes, car cela permet d'empêcher la venue de problèmes provenant de listes de mots clés dans différentes versions de PostgreSQL™.

Il y a 2 questions dans votre message:
- comment créer un serveur PostgreSQL répliqué sous Windows: c'est censé fonctionner comme sur Linux à part les spécificités Windows (syntaxe des noms de fichiers, service Windows pour l'instance/cluster)
- comment synchroniser les documents numérisés en dehors de la base: je ne sais pas si PostgreSQL sait faire ? En général on utilise des outils simples comme robocopy sur Windows ou rsync sur Linux ou des outils plus complexes comme DFS sur Windows ou DRBD sur Linux.
Que voulez-vous savoir en détail  ?

Bonjour,

Essayez de donner tous les droits à l'utilisateur 'NETWORK SERVICE' sur le répertoire DATA.

Pour vous aider, il  faut avoir la description complète des tables concernées, la correspondance entre les colonnes et un exemple de MAJ: quand est-ce qu'il faut la faire et quand est-ce qu'il ne faut pas la faire.

D'après le support de formation Dalibo (les outils de réplication):

L’outil repmgr3 de 2ndQuadrant permet la gestion de la haute disponibilité avec notamment la gestion des opérations de clonage, de promotion d’une instance en primaire et lad émotion d’une instance.L’outil repmgr peut également être en charge de la promotion automatique du nœud secondaire en cas de panne du nœud primaire, cela implique la mise en place d’un serveur supplémentaire par cluster HA (paire primaire/secondaire) appelé témoin (witness). Cette machine héberge une instance PostgreSQL dédiée au processus daemon repmgrd, processus responsable d’effectuer les contrôles d’accès réguliers à l’instance primaire et de promouvoir le nœud secondaire lorsqu’une panne est détectée et confirmée suite à plusieurs tentatives échouées consécutives.Afin de faciliter la bascule du trafic sur l’instance secondaire en cas de panne du primaire,l’utilisation d’une adresse IP virtuelle (VIP) est requise. Les applications clientes (hors administration) doivent se connecter directement à la VIP.

Ce concept de  témoin est un concept général souvent utilisé dans les systèmes de haute-disponibilité.