Forums PostgreSQL.fr

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é.

Est-ce que vous avez des traces détaillées des checkpoints avec log_checkpoints=on ? Si oui, pouvez-vous les partager ?
Est-ce que vous avez une estimation du volume de WAL générés pendant la mise à jour et la durée de la mise à jour ?

En 9.3 Les paramètres checkpoint_xxx sont tous statiques et nécessitent un arrêt/relance. Si vous les modifiez et si log_checkpoints est à off, pensez aussi à mettre  log_checkpoints à on.
En général on peut modifier checkpoint_segments et checkpoint_completion_target ensemble: vous pouvez augmenter checkpoint_segments à 10 ou 20 et checkpoint_completion_target à 0,9 pour lisser davantage les écritures.

Si vous avez de la place dans /tmp vous pouvez aussi essayer:

\copy (SELECT * FROM maTable) TO '/tmp/export.sql' DELIMITER ',' CSV;

Pas mieux:

set datestyle='dmy';
SET
with cte as
( 
 select justify_interval(('23-03-2020 16:00'::timestamp - '19-01-2020 06:30'::timestamp) 
                       + ('19-03-2020 06:30'::timestamp - '15-01-2020 06:30'::timestamp))
 as intervalle 
)
select 
extract(year from intervalle)      || ' an(s) '    ||
extract(month from intervalle)     || ' mois(s) '  || 
extract(days from intervalle)      || ' jours(s) ' || 
extract(hours from intervalle)	   || ':'          || 
extract(minutes from intervalle) as durée
from cte;
               durée               
-----------------------------------
 0 an(s) 4 mois(s) 8 jours(s) 9:30
(1 ligne)

select 
to_char(justify_interval( ('23-03-2020 16:00'::timestamp - '19-01-2020 06:30'::timestamp)
+                         ('19-03-2020 06:29'::timestamp - '15-01-2020 06:30'::timestamp)),
'y "ans" mm "mois" DD "jour(s)" HH "heure(s)" MI "min"' ) as durée;
                    durée                    
---------------------------------------------
 0 ans 04 mois 08 jour(s) 09 heure(s) 29 min
(1 ligne)

Je n'arrive pas à reproduire le résultat ni avec PG 12.2 ni avec PG 9.4.26:

postgres=# select '23-03-2020 16:00'::timestamp - '15-03-2020 06:30'::timestamp;
    ?column?     
-----------------
 8 days 09:30:00
(1 ligne)

Que donne le résultat de ma requête dans votre environnement ?
Quelle est votre version ?

Je n'arrive pas non plus à passer en français même avec le paramétrage suivant:

postgres=# set datestyle to 'DMY';
SET
postgres=# set lc_messages='fr_FR.UTF-8';
SET
postgres=# set lc_time='fr_FR.UTF-8';
SET
postgres=# select '23-03-2020 16:00'::timestamp - '15-03-2020 06:30'::timestamp;
    ?column?     
-----------------
 8 days 09:30:00
(1 ligne)

postgres=# 

Remarque générale qui n'explique pas le problème précis qu'on a: au début de la discussion vous avez dit que vous prévoyez d'avoir une base sur Linux et vous développez avec une base Windows. Si vous utilisez la même version de PostgreSQL vous devez avoir en général le même comportement de la base mais pas sur certaines fonctionnalités liées aux jeux de caractères car PostgreSQL peut avoir un comportement différent liés aux paramètres de création de la base qui ne sont pas les mêmes sur Windows et Linux. Ainsi si je crée une base sur Linux avec PG 10.12 j'ai par défaut:

postgres=# create database demo;
CREATE DATABASE
postgres=# \l demo;
                             List of databases
 Name |  Owner   | Encoding |   Collate   |    Ctype    | Access privileges 
------+----------+----------+-------------+-------------+-------------------
 demo | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
(1 row)

postgres=# 

Je constate que le paramètres LC_COLLATE et LC_CTYPE sont différents avec Windows: ce qui peut entraîner des comportements différents, par exemple dans le tri de chaînes de caractères.

OK mais comment fait-on avec Windows ?

Pouvez-vous nous donner la sortie complète  du script suivant exécuté dans le même environnement que script2.txt:

\encoding
show client_encoding
\l intensetbm
INSERT INTO adm_pay (pay_nom_eng,pay_nom_fra,pay_abr) VALUES ('Ivory Coast','Côte d Ivoire','CIV');
select * from_adm_pay where pay_abr='CIV';