L'option -R permet de générer un fichier recovery.conf pour la restauration.

Si le fichier .ready est présent mais pas le wal lié, ça créée ce genre de message quand le moteur essaye d'archiver

Si la valeur est commentée.... et qu'elle n'a jamais été modifiée, c'est la valeur par défaut (et actuellement prise en compte) qui est renseignée.

Pour ne pas avoir de doute, je vous conseille d'aller voir la table pg_settings: il y a la valeur actuelle du paramètre et la valeur par défaut.

De mon point de vue, pg_repack recréée les indexes car il créée une nouvelle table lors de la réorganisation, donc oui, on peut dire qu'il réindexe.

De ce que je vois de l'aide, on peut aussi changer le TBS pour les data et indexes mais je n'ai jamais utilisé cette fonctionnalité: http://reorg.github.io/pg_repack/

Je comprends bien mais je ne souhaite pas vraiment mettre des informations détaillées de schéma sur un forum public...ce que je peux vous donner comme infos qui me paraissent intéressantes

La table mère
CREATE TABLE A (
    id bigint,
    struct_id int,
   ....
   ....
);

Les tables filles
CREATE TABLE A_%s
CHECK (struct_id = %s),
CONSTRAINT my_pkey PRIMARY KEY (struct_id, id)
) INHERITS (A);

La table mère possède un trigger qui permet de créer les tables filles
Les tables files ont un ensemble d'index et leurs propres triggers.

On ne travaille quasiment jamais sur la table mère, tous les traitement sont lancés directement sur les tables filles.

Moi je vous répondais sur le problème de systemd par sur la problématique générale de l'industrialisation... Si  j'ai eu à installer du PG avec les paquets RHSCL, ce n'est pas par choix mais par obligation.... comme vous ;p . Pour certains entreprises, l’industrialisation , c'est de rester conforme au socle système et donc aux paquets fournis par redhat (je suppose pour une histoire de support) . De plus, il n'est souvent pas possible d'introduire des dépôts externes sur les environnements de production, d'où la difficulté d'utiliser les dépôts officiels PG.

Après utiliser PG depuis les dépôts RHSCL me parait un moindre mal par rapport à celui d'utiliser une version obsolète fournie de base en RH7 (9.2). Et l’industrialisation... je pense que ça doit pouvoir s'adapter quand même

Pour moi, les nommer peut aussi simplifier l'administration car avec seulement le nom de la contrainte, on sait quel(s) table(s), colonne(s), sont concernées et quel est le type de contrainte. De plus, si le DBA gère plusieurs moteurs de BDD, différents, ça permet d'avoir une cohérence globale, car certains moteurs (Oracle pour ne pas le nommer) ont un nommage par défaut des contraintes "assez exotique".
L'avantage de PG est que le nommage par défaut est déjà assez explicite, d'où mon interrogation sur l'intérêt d'en faire plus.

Ah ok, ça me parait logique comme ça.

Du coup, le moteur anticipe les fichiers dont il va avoir besoin en renommant un certain nombre d'ancien WAL ? Si c'est la cas, combien en pré-alloue t'il ? C'est basé sur le max_wal_size ? checkpoint_timeout ?

Merci, je vais regarder ça

Bonjour Gleu,

Merci pour le retour.
Le problème est que le traitement passe sur d'autres environnements, où notamment les paramètres mémoires clients sont plus hauts (work_mem par exemple). Je vais tester en augmentant work_mem

Pourquoi ne pas créer un lun + target iscsi ?