Vous n'êtes pas identifié(e).
Si l'article ne mentionne pas le fait que pgbackrest sauvegarde l'instance complète, c'est que c'est justement une limitation de PostgreSQL et pas une limitation de pgbackrest. Même si pgbackrest sait restaurer une seule base, cette "fonctionnalité" est pour moi un contournement pas très propre.
Sans plus d'infos, difficile de dire quoi que ce soit. Il va falloir bien plus détailler votre demande.
Vous voulez parler du nombre de blocs lus ? c'est disponible dans les colonnes blks_read et blks_hit de la table pg_stat_database.
Je ne crois pas que YON utilise /tmp pour son export. pg_dump le fait tout seul lors de l'utilisation du format tar. Les explications de Tom Lane sur ce comportement :
Tar format is sufficiently weird that we have to dump data into a temp
file and then append it to the archive after we know its exact size.
This means double copying of data, as well as problems if your temp
directory is in an undersized filesystem. On the whole, custom format
is a lot better bet from a performance standpoint --- so we only
recommend tar format if you have a clear need to be able to disassemble
the archive with non-Postgres tools.
Quant à la corriger ce comportement, testez avec la variable d'environnementTMPDIR mais toujours d'après Tom Lane :
The temp files are created with the standard library function tmpfile().
If you think that's behaving improperly, take it up with your OS vendor.
I suspect they'll tell you it would be a security risk for that function
to respond to environment variables.
Bref, le mieux est certainement d'oublier le format tar et de passer par le format custom (ou directory).
Quel est la commande complète que vous lancez ?
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 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.