PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 Re : Général » Problème d'espace disque occupé par les fichier du repertoire PG_WAL » 11/03/2024 09:29:13

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.

#2 Re : Général » pg_basebackup et propriétaire des fichiers de l'instance postgres » 01/03/2024 21:55:01

Je n'avais jamais remarqué mais, en effet, vous avez raison.

Il n'existe malheureusement pas d'option pour changer cela.

#3 Re : pgAdmin4 » Erreur de syntaxe impossible à expliquer » 01/03/2024 21:48:18

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$';

#5 Re : Général » plus d'accès à la structure de mes tables ! » 13/02/2024 10:54:10

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)

#6 Re : Général » plus d'accès à la structure de mes tables ! » 12/02/2024 10:45:20

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).

#7 Re : Réplication » Switchover sans perte de données » 16/01/2024 16:36:06

* 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.

#8 Re : Site PostgreSQL.fr » Comment être référencé dans la rubrique Professional support » 01/01/2024 22:41:53

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.

#9 Re : Réplication » [Résolu] réplication d'un cluster de prod vers un serveur test » 26/10/2023 21:59:43

Aucune opération DDL (sauf TRUNCATE) n'est répliquée dans une réplication logique.

#11 Re : PL/pgSQL » Probleme : SQL Error [42601]: Unterminated dollar quote » 14/10/2023 21:41:49

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.

#12 Re : Général » Segmentation fault » 27/09/2023 09:08:44

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.

#13 Re : Installation » pointer vers une BDD correspondant au nom de connexion » 19/09/2023 11:30:38

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.

#14 Re : Réplication » chaine de connexion à un cluster Patroni / pgs14 » 30/08/2023 11:45:34

Ç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).

#15 Re : Général » l'identifiant de pg_stat_statement » 30/08/2023 11:41:57

pg_stat_statement est une vue. De ce fait, il n'y a pas de clé primaire.

#16 Re : Installation » PostgreSQL 15 - impossible de modifier adresse et port écouté » 07/08/2023 18:33:39

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.

#17 Re : Général » Mots triés différemment entre Postgresql 12 et Postgresql 15 » 07/08/2023 18:26:27

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 ?

#18 Re : Général » Droits USER - Vues matérialisées FDW et QGIS » 04/08/2023 09:02:50

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 smile ) 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.

#19 Re : Optimisation » Fragmentation des tables et indexes » 31/07/2023 15:31:03

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.

#20 Re : Optimisation » Fréquence optimale pour le Vacuum (full ou simple), reindex, analyze » 28/07/2023 09:30:07

S'il y avait une règle, PostgreSQL le ferait lui-même smile

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.

#22 Re : Migration » Update Postgis après migration pg11 vers pg13 » 07/07/2023 08:41:16

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.

#23 Re : Général » pg_basebackup et sspi » 07/07/2023 08:40:04

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.

#24 Re : Général » Choix architecture » 07/07/2023 08:37:06

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.

#25 Re : Migration » Update Postgis après migration pg11 vers pg13 » 05/07/2023 15:51:59

Sans les erreurs, difficile d'être certain, mais il y a de fortes chances que vos vues utilisateurs doivent être recréés.

Pied de page des forums

Propulsé par FluxBB