Vous n'êtes pas identifié(e).
Le FETCH ALL IN d'après ce que j'ai compris cela veut dire que cela viendrait d'une procédure/ une fonction, c'est cela ?
Pas forcément, FETCH ALL est une requête SQL. Elle peut simplement faire partie d'une transaction.
Si ça a été exécuté au sein d'une fonction, je ne vois pas comment vous pouvez trouver a posteriori cette fonction. Il faudrait tracer toutes les requêtes pour remonter le fil et encore, vu qu'elle termine en erreur, elle ne sera pas tracée.
Comment pouvons nous savoir quelle procédure ou requête a généré ce Segmentation fault ?
Vous avez déjà la requête, c'est le FETCH ALL, même si j'avoue qu'elle n'aide pas beaucoup.
Sur les logs du client qui a généré cette segmentation fault (retrouvé grace au PID) je n'ai pas de dumpstack aucune erreur (pas d'erreur de requête)
Un peu normal, c'est pas le client qui a planté, mais le processus serveur.
Sans moyen de reproduire l'erreur, il va être très compliqué de corriger ça.
Ce n'est pas le pg_hba.conf qui va indiquer la base, mais la chaîne de connexion.
Par contre, si vous voulez forcer votre utilisateur à ne se connecter qu'à la base de son nom, c'est possible, et ça se fait via le fichier pg_hba.conf.
Ça n'existe pas et ça ne peut pas exister. L'option que vous donnez est utilisée uniquement à la connexion. Elle vous assure que votre connexion se fait directement sur le bon serveur en lecture/écriture. Si jamais ce serveur change de rôle, la connexion étant déjà établie, vous restez sur le même serveur. Il faudrait que l'outil (psql ici) ait une option de vérification du type de connexion qui le contraigne à vérifier régulièrement l'état du serveur. Cette option n'existe pas (mais pourrait être ajoutée dans une prochaine version, même si ça me paraît peu probable).
pg_stat_statement est une vue. De ce fait, il n'y a pas de clé primaire.
Première chose qui me chagrine : vous indiqué que le paramètre port est configuré à 5552, et lsof parle d'un port 5432 pour PostgreSQL. Ce n'est pas cohérent.
De plus, je ne vois pas comment ceci pourrait fonctionner :
host all all 0.0.0.0/0 reject
hostssl all all 0.0.0.0/0 md5Vous rejetez forcément toutes les connexions extérieures provenant d'adresses IPv4. Si les deux lignes étaient inversées, là, ça fonctionnerait uniquement en SSL.
N'auriez-vous pas profité du changement de version de PostgreSQL pour mettre à jour tous les paquets systèmes, voire la version du système d'exploitation ?
Voilà...je ne sais pas si quelqu'un peut m'aider à résoudre ce problème ?
Avez-vous essayé de lire la vue matérialisée avec psql ? ne connaissant pas qgis plus que ça, je ne sais pas exactement ce qu'il cherche à faire. Avec psql, c'est beaucoup plus simple (pour moi en tout cas 
) d'investiguer un problème de droits d'accès.
Par contre j'ai une erreur quand je veux visualiser les données de la vue public.gemetry_columns : "droit refusé pour la fonction postgis_typmod_dims" ... je ne sais pas comment modifier ce genre de droits ?
Il faut qu'il ait le droit EXECUTE sur la fonction.
Le nombre de lignes (ou son pourcentage) n'est pas une info suffisante. Il est plus justifié de parler en octets, et cela dépend aussi de la quantité de RAM disponible. Bref, encore une fois, difficile de donner une valeur comme ça.
S'il y avait une règle, PostgreSQL le ferait lui-même
Une règle non automatisable serait : il faut faire un VACUUM quand la fragmentation est importante (mais c'est à chaque DBA de quantifier ce "important") Pour le REINDEX, pareil, tout dépend de la fréquence de fragmentation des index.
En lisant les posts du forum j'avais cru comprendre qu'il ne fallait pas trop faire d'analyze
Absolument pas. D'ailleurs, l'autovacuum est configuré pour faire deux fois plus d'ANALYZE que de VACUUM (en gros).
et que faire souvent des vacuum permettait de ne pas avoir besoin de faire souvent des vacuum full.
Exact. VACUUM FULL ne doit pas être une opération automatique et planifiée. C'est utilisable au cas par cas, quand un DBA estime que c'est nécessaire.
Non, pas possible.
Je suppose que la requête est un DROP. Dans ce cas, pas d'autres solutions que de supprimer la vue, puis la recréer.
L'authentifcation n'est pas gérée par les outils mais par le serveur. Donc le problème ne vient pas de pg_basebackup.
Pour qu'on puisse vous aider, il serait bien de fournir le fichier pg_hba.conf, les commandes complètes pg_dump (qui fonctionne comme vous l'espérez si j'ai bien compris) et pg_basebackup (qui ne fonctionne pas comme vous l'espérez), ainsi que les messages d'erreur.
Je plussoie complètement ce qu'a dit Julien. Cependant, si vous voulez stocker des documents dans une base, il faudra utlliiser soit des Large Objects, soit des colonnes de type bytea. bytea est préférable pour de nombreuses raisons.
Quant à la question des performances, c'est impossible à dire actuellement.
Personnellement, ce qui m'interroge le plus, c'est comment vous comptez sauvegarder une telle volumétrie, quelle rétention vous allez appliquer, quels sont vos RTO et RPO.
Sans les erreurs, difficile d'être certain, mais il y a de fortes chances que vos vues utilisateurs doivent être recréés.
La commande indiquée par archive_cleanup_command est exécutée uniquement lors d'un restartpoint, autrement dit uniquement sur un secondaire. Cela ne semble pas être votre cas ici.
Si votre dossier "A" ne contient que des WAL archivés, vous pouvez les supprimer comme vous voulez, ça n'empêchera pas PostgreSQL de fonctionner correctement. Cependant, vous devez conserver les WAL nécessaires pour une restauration PITR. Ce répertoire est apparemment cloné sur un serveur distant, mais vous n'indiquez pas à quel fréquence il l'est, ni si les fichiers sources supprimés sont aussi supprimés de la destination lors du clonage. Bref, comme la seule info que j'ai est que vous lancez pg_basebackup une fois par mois, il est essentiel que vous conserviez tous les WAL depuis la dernière sauvegarde. Si vous voulez avoir une rétention plus importante (2, 3 sauvegardes), vous devez garder autant de mois de WAL. Vous pouvez utiliser pg_archivecleanup manuellement pour faire ça en lui indiquant le répertoire d'archivage (donc le dossier "A") et le plus ancien fichier archivé à conserver.
Pas besoin de supprimer le thread, ça peut servir de documentation à d'autres si vous expliquez ce qui posait problème (problème de PATH, je suppose ?).
Vous ne devez avoir qu'une seule déclaration du dépôt. Et étant donné leurs différences, je pencherais plutôt pour supprimer pgd.list.
Pourquoi a-t'il besoin de ce fichier? Dans le dossier wal, il n'y a que des .wal, pas autre chose...
Non, il peut aussi y avoir des fichiers .hitstory dans le cas d'un ou plusieurs changements de timeline.
Pourquoi pas de recovery?
Le dossier /var/lib/pgsql/13/wal contient quoi exactement ? des wal archivés ou des wal en cours de gestion par l'ancien serveur ?
La seule hypothèse que j'arrive à faire est que ce sont des wal en cours de gestion par l'ancien serveur. Au moment de la sauvegarde, le serveur en était au wal 15, les 16 et 17 étaient créés en avance.
De ce fait, lors de la restauration, PostgreSQL détecte qu'il est en mode recovery, et lance le recover à partir du dernier checkpoint. Il rejoue le journal 15 partiellement vu que ce dernier n'était pas terminé à la fin de la sauvegarde. Et du coup, il ignore les fichiers suivants qui ne contiennent aucune information intéressante. Une timeline 2 est créé vu qu'il est arrivé en fin de rejeu. L'activité commence ce qui lui fait générer les wal 15 (la fin), 16, 17, etc sur la timeline 2.
Questions: pourquoi une seconde timeline?
En fin de recovery, il bascule tout le temps sur la timeline suivante. Vous étiez sur la 1, il passe donc à la 2.
PostgreSQL ne cherche pas à écrire dans ce répertoire, il cherche à lire. Son problème est qu'il ne trouve pas ce fichier. Difficile de dire pourquoi vu qu'on a qu'un extrait des traces.
J'ai déplacé la discussion dans la thématique associée.
Concernant votre demande, les bases de données sont des blocs hermétiques. À partir d'une connexion à une base, vous ne pouvez pas requêter les objets d'une autre base. Il faut passer par une autre connexion. Le plus simple revient à utiliser la norme SQL/MED avec le foreign data wrapper postgres_fdw. Vous aurez les renseignements nécessaires sur https://docs.postgresql.fr/15/postgres-fdw.html
Elles passent "deferred". Cependant, comme la documentation l'indique, elles passent uniquement pendant le temps de la transaction. Donc au COMMIT, pouf, le mode "DEFERRED" est annulé. À ma connaissance, pg_restore ne peut pas le faire. Il faut donc créer votre propre solution (une version personnalisée de pg_restore semblerait le plus simple).
Pourquoi ne pas utiliser une valeur par défaut à la place ? ce serait plus performant.
Il ne vous reste plus qu'à mettre à jour votre version de PostgreSQL
Avec un LIMIT, vous demandez à PostgreSQL de favoriser le coût de départ et non pas le coût final. Faire un Sort a un coût de départ très fort, donc pour ne pas faire le tri, il bascule sur la lecture d'index (les données sont déjà triées dans un index). ET même si lire un index est rapide (0.02 ms ici), si vous le lisez 4 millions de fois (3951204 exactement), forcément ça prend beaucoup de temps.
Comment faire pour améliorer ça? Déjà, commencer par mettre à jour votre serveur PostgreSQL. D'après https://why-upgrade.depesz.com/show?fro … &keywords=, vous avez 479 bugs non corrigés sur votre version et une recherche rapide montre que le planificateur/optimiseur a quelques bugs de corrigé. Pas sûr que ça corrige votre problème, mais ça devrait déjà être la première étape.
Pourquoi ai je besoin de mettre des quotes autour de ma valeur décimale pour que le select me retourne mes entrées ? une histoire de stockage d'un arrondi de ma valeur ?
Un real n'est pas l'idéal pour des comparaisons et des calculs stricts. Le problème est en effet certainement un problème d'arrondi et de type de données
Le format real choisi n'est peut être alors pas adapté si je peux effectuer ce genre d'égalité stricte ?
Tout dépend de ce que vous voulez faire. Mais en soit, les types real (ou float4) et double precision (ou float8) ne permettent pas de comparaison et de calcul stricts. Il faut mieux passer par numeric, plus lent mais plus sûr.
Faut il systématiquement mettre la valeur ciblée dans mon select entre ' ' pour être certain de ne rien rater lors de la requête ??
Non, pas forcément. Tout dépend de ce que vous cherchez. Quand vous écrivez "where champ = 41.4", vous ne précisez pas le type de données de champ et il doit donc le deviner. Il peut choisir numeric, float4 ou float8. Pour ne pas perdre en précision, il prendra le plus gros, avec float8, ce que nous indique d'ailleurs la commande EXPLAIN ;:
? on postgres@r15 =# explain select id_station,doc,chla from ma_table where profondeur=41.4;
┌──────────────────────────────────────────────────────────┐
│ QUERY PLAN │
├──────────────────────────────────────────────────────────┤
│ Seq Scan on ma_table (cost=0.00..33.12 rows=9 width=12) │
│ Filter: (profondeur = '41.4'::double precision) │
└──────────────────────────────────────────────────────────┘
(2 rows)Avec les problèmes d'arrondi des types float4 (real) et float8 (double precision), il y a de fortes chances que la comparaison indique une inégalité. Si on le mettait de force en float4, la comparaison renvoie une égalité. Par exemple, ces quelques tests ;:
? on postgres@r15 =# select 41.4::float4=41.4::float4;
┌──────────┐
│ ?column? │
├──────────┤
│ t │
└──────────┘
(1 row)
? on postgres@r15 =# select 41.4::float8=41.4::float8;
┌──────────┐
│ ?column? │
├──────────┤
│ t │
└──────────┘
(1 row)
? on postgres@r15 =# select 41.4::float4=41.4::float8;
┌──────────┐
│ ?column? │
├──────────┤
│ f │
└──────────┘
(1 row)Utiliser les guillemets sans contraindre le type semble quand même le convertir en real/float4.
? on postgres@r15 =# explain select id_station,doc,chla from ma_table where profondeur='41.4';
┌──────────────────────────────────────────────────────────┐
│ QUERY PLAN │
├──────────────────────────────────────────────────────────┤
│ Seq Scan on ma_table (cost=0.00..33.12 rows=9 width=12) │
│ Filter: (profondeur = '41.4'::real) │
└──────────────────────────────────────────────────────────┘
(2 rows)Je ne suis pas certain que cela soit marqué dans le dur ceci dit. Mieux vaut contraindre le type de données pour s'assurer d'une requête exécutée de façon identique partout ailleurs.
Donc pour moi, soit vous changez le type de données par numeric, soit vous convertissez vos valeurs dans le type de données de la colonne (ça peut devenir problématique si elles changent de type).