Vous n'êtes pas identifié(e).
J'ai tout de suite désactivé l'option dans le fichier de configuration de postgresql.
Quel option ?
Cependant je voudrais savoir si je peux supprimer les fichier du répertoire "pg_wal"? Est ce qu'il n'y aurait pas d'impact sur la base de données?
Surtout pas, la base serait à coup sûr corrompue.
Je n'avais jamais remarqué mais, en effet, vous avez raison.
Il n'existe malheureusement pas d'option pour changer cela.
Julien vous a déjà répondu sur ce point. REGEXP n'est pas un opérateur. Soit votre support de cours contient une erreur, soit vous n'avez pas compris son contenu. L'opérateur habituel pour les expressions rationnelles est le tilde ~, ce qui donnerait pour votre exemple :
SELECT*
FROM "DLC".clients
WHERE nom ~ '^D|E$';
Pour les pivots, l'extension tablefunc est intéressante : https://www.postgresql.org/docs/16/tablefunc.html
N'auriez vous pu exécuter un \o fichier, ce qui a pour effet d'envoyer le résultat dans ce fichier ? un moyen d'annuler tout "\o fichier" est de faire un \o seul. Par exemple :
postgres@r16 =# select * from pg_am;
┌──────┬────────┬──────────────────────┬────────┐
│ oid │ amname │ amhandler │ amtype │
├──────┼────────┼──────────────────────┼────────┤
│ 2 │ heap │ heap_tableam_handler │ t │
│ 403 │ btree │ bthandler │ i │
│ 405 │ hash │ hashhandler │ i │
│ 783 │ gist │ gisthandler │ i │
│ 2742 │ gin │ ginhandler │ i │
│ 4000 │ spgist │ spghandler │ i │
│ 3580 │ brin │ brinhandler │ i │
└──────┴────────┴──────────────────────┴────────┘
(7 rows)
postgres@r16 =# \o /tmp/pouet
postgres@r16 =# select * from pg_am;
postgres@r16 =# \d pg_am
postgres@r16 =# \o
postgres@r16 =# select * from pg_am;
┌──────┬────────┬──────────────────────┬────────┐
│ oid │ amname │ amhandler │ amtype │
├──────┼────────┼──────────────────────┼────────┤
│ 2 │ heap │ heap_tableam_handler │ t │
│ 403 │ btree │ bthandler │ i │
│ 405 │ hash │ hashhandler │ i │
│ 783 │ gist │ gisthandler │ i │
│ 2742 │ gin │ ginhandler │ i │
│ 4000 │ spgist │ spghandler │ i │
│ 3580 │ brin │ brinhandler │ i │
└──────┴────────┴──────────────────────┴────────┘
(7 rows)
postgres@r16 =# \d pg_am
Table "pg_catalog.pg_am"
┌───────────┬─────────┬───────────┬──────────┬─────────┐
│ Column │ Type │ Collation │ Nullable │ Default │
├───────────┼─────────┼───────────┼──────────┼─────────┤
│ oid │ oid │ │ not null │ │
│ amname │ name │ │ not null │ │
│ amhandler │ regproc │ │ not null │ │
│ amtype │ "char" │ │ not null │ │
└───────────┴─────────┴───────────┴──────────┴─────────┘
Indexes:
"pg_am_oid_index" PRIMARY KEY, btree (oid)
"pg_am_name_index" UNIQUE CONSTRAINT, btree (amname)
C'est en effet très étonnant. Quand vous faites \d nom_table dans psql, il ne vous rend rien ou il vous rend l'invite de commande ? (s'il ne vous rend rien, c'est que le serveur est bloqué à faire quelque chose alors que s'il vous rend l'invite, c'est qu'il a terminé son travail).
* est-il possible de faire en sorte que le primaire stoppe si le standby est déconnecté?
Automatiquement non. Il vous faut un script qui arrête le secondaire une fois qu'il a détecté la déconnexion du secondaire.
* la solution "préconisée" pour faire un switchover est de couper le primaire puis faire un "promote" sur le standby. En coupant le primaire, ne risque-t'on pas d'arrêter la réplication en cours et donc de créer un gap entre le primaire et le standby?
Non. Ce qui a été envoyé est rejoué. Les transactions pour lesquelles le COMMIT n'est pas arrivé ne sont pas prises en compte.
* Y a-t'il un script à tourner sur le primaire , au cas où ils ne serait plus connecté, de mettre quelque part les wal non reçus par le standby (wals qui seraient envoyés manuellement)?
C'est normalement le but du paramètre archive_command.
* quand on coupe le primaire, s'assure-t'il de transmettre jusqu'au dernier wal vers le standby avant de s'arrêter?
S'il est coupé, il ne peut rien faire. C'est donc à réaliser manuellement.
Il vous suffit d'avoir un compte sur le site (que vous pouvez créer ici : https://www.postgresql.org/account/signup/) et de déclarer votre société directement sur la page d'accueil de votre compte. La déclaration sera validée ensuite par un modérateur.
Aucune opération DDL (sauf TRUNCATE) n'est répliquée dans une réplication logique.
Quel est le message d'erreur exact ?
Il y a plein d'erreurs dans ce code. On peut commencer avec les guillemets doubles qui doivent être remplacés par des guillemets simples mais doublés. Ceci n'est peut être pas à faire car la présence du format me parait très douteuse. Pour moi, c'est "EXECUTE INSERT... USING...".
Et enfin, le "Unterminated dollar quote" me paraît peu croyable pour cette fonction.
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 md5
Vous 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.