Forums PostgreSQL.fr

Bonjour,

J'utilise la version 14.5 de PostgreSQL avec RedHat8.5

Dans le fichier de configuration "postgresql.auto.conf" on trouve les mentions suivantes:
# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.

Il se trouve qu'il a les mêmes comportements que le fichier postgtresql.conf.
* on peut modifier, supprimer, ajouter manuellement n'importe quel paramètre de PostgreSQL avec un éditeur (tel que vi, vim...) après un reload ou restart, il prend en compte.

J'avais une (mauvaise) compréhension que les paramètres (dans postgresql.auto.conf), ne seront prises en compte que s'ils sont mises ou modifiés via les ordre SQL "ALTER...set/reset  <param> ;

J'ai vu dans dans un article de Michael Paquier ce commentaire:
"So basically avoid to modify it manually as this is used for ALTER SYSTEM. When a parameter is modified, a temporary file called postgresql.auto.conf.temp is created to rollback to the original state in case of error."
Quel est l'empleur du mot "basically"? juste pour la forme!? ou il y a vraiment une contrainte technique?

Mes interrogations:
1- Est ce que le comportement était toujours comme ceci ou il a changé pour ce fichier de configuration "postgresql.auto.conf".
2- A quel moment le fichier "postgresql.auto.conf.temp" apparait, car je n'ai pas pu mettre la main dessus ( comment faire un test correctement pour le voir?).
3- Hormis l'aspect interactif du changement des paramètres journalisés dans ce fichier quel est le plus par rapport aux paramètres (include_dir, include et include_if_exists)?
4- la mise en garde au début du fichier (Do not édit....), c'est pourquoi à votre avis?

Merci pour vos réponses

B.LEMJID

Bonjour,

Je remet le sujet de maintenance que j'ai demandé de l'aide et j'ai eu des réponse de "rjuju" et "gleu", je les remercie encore.
Après avoir ajuster les paramètres spécifiques de quelques relations (tables):
AUTOVACUUM_ANALYZE_SCALE_FACTOR
AUTOVACUUM_VACUUM_SCALE_FACTOR
AUTOVACUUM_FREEZE_MAX_AGE

Ordonnancer un traitement VACUUM/ANALYZE régulier ciblé.
=> J'ai bénéficié un résultat bien correcte, c'est le moins qu'on puisse le dire.

Je signale aussi que j'ai pu bénéficié des mise à jours HOT des lignes et ça fonctionne bien aussi. Donc l'augmentation de la taille des tables est correcte et le seuil du "bloat" aussi

Le seul bémol c'est qu'au niveau des indexes l'augmentation de la taille est conséquent.
Étant en version 11.9, ne pouvant pas bénéficier de l'option (concurrently '12+'), ne pouvant pas utiliser "pg_repack ou autres outils, je ne peux que faire un "REINDEX 'index xxxxx'"!
Le problème que je n'ai pas de fenêtre de maintenance (application 7/24).
En pensant faire un "pg_terminate_backend()" puis lancer un reindex derrière et refaire ceci pour chaque index, le risque est de perdre les transactions en cours.
Je peux aussi essayer de récupérer les transactions en allant les chercher avant le "pg_terminate_backend()" dans "pg_stat_activity.query" mais certaines requêtes ont des variables pour des valeurs non connues de type (INSERT into tablename col1 col2... values ($1,$2,$3...etc.) les UPDATE aussi).

Ma question:

* Y a t il une (des) idée(s) afin de passer entre les goutes:
- Passer le ré-index de qq tables (temps estimé <30 min.) en évitant en éventuel blocage.
- Une façon plus fiable pour récupérer les transactions avortées lors de la réindexation "pg_terminate_back_end".

Par avance merci

B. LEMJID

Bonjour tout le monde,

Par manque de documentation je voudrai savoir si quelqu'un à un retour d'expérience avec pg_squeeze?
Le problème c'est que je ne peux pas scheduler une tâche sur une table.
Il est expliqué dans la documentation (https://github.com/cybertec-postgresql/pg_squeeze), qu'il faut renseigner la table (squeeze.tables) surtout la colonne (schedule) qui contient la paramètre de la date(jour de la semaine)/heure
du déclenchement.
Pour ma part j'ai renseigner cette table mais rien ne se passe.
Je surveille le log PostgreSQL (log_min_duration_statement='0'), je n'ai rien vu et la taille de la table bloatée est toujours le même?!
en revanche quand j’exécute la fonction "SELECT squeeze.squeeze_table('squeeze', 't_test', null, null, null);" ça fonctionne et la taille de la table diminue.
les paramètres :
squeeze.worker_autostart = 'ma_base'
squeeze.worker_role = 'postgres'
sont bien renseignés
J'ai aussi modifié ces paramètres "free_space_extra,min_size et vacuum_max_age" dans (tables) en diminuant leurs valeurs toujours rien ne se d’éclanche; en tout cas la table est toujours bloatée et je ne voit d'erreur 

Est ce que j'ai oublié une/des étapes

Par avance Merci

Bonjour,

Depuis qu'on a commencer les mises à jour PostgreSQL de 9.X vers 11.X (11.5, 11.7 et 11.9), on a constaté un message d'erreur à répétions:
"FATAL:  unsupported frontend protocol 1234.5680: server supports 2.0 to 3.0"
Ce que je peux voir, c'est que ce message vient des serveurs apache.
J'ai vu sur le net qu'il concerne la connexion avec encryption "GSSAPI" et qu'il suffit de mettre:
GSSENCMODE=disable dans les variables d'environnement PostgreSQL sinon dans la chaine de connexion à la base.
J'ai vu même que c'est faisable lors de la compilation des binaires PostgreSQL. Pour nous c'est les RPMs qu'on utilise pour l'installation de PostgreSQL.

Pour moi cette recommandation n'a pas marché! Soit je n'ai pas bien fait les choses ou j'ai manqué une étape!
Est ce que quelqu'un a une idée SVP.

Par avance merci.