Vous n'êtes pas identifié(e).
Le probleme vient du fait que les paquets de red hat ne sont pas compatible avec plusieurs versions majeures de postgres. Pour faire ce que vous voulez il vous faut donc supprimer le paquet red hat, reinstaller la version 13 via les pquets du pgdg et installer la version 15 egalement via les pquets du pgdg.
Comment avez-vous installe pg13 et pg15 ?
Bonjour,
Difficile de répondre avec aussi peu d'informqtions, mais à priori je dirais que votre "solution" a pour effet de corrompre vos données.
Pourriez-vous donner plus de détails, par exemple les logs correspondant à un crash; la configurqtion de postgres et toute infor,qtion pertinente.
WIN1252 ne peut pqs représenter tous les caractères existant en UTF-8, il n'y a donc pas trop de solution facile. Soit vous migrez votre base pour la stocker en UTF-8, soit vous faites en sorte de n'envoyer que des caractères valides en WIN1252.
Impossible de repondre sans savoir l'option que vous avez desactivee.
Bonjour;
La question se pose plus généralement sur les nets avantages que peut procurer le partitonnement. Par exemple pouvoir effectuer un DROP plutôt qu'un DELETE si votre partitionnement est bien pensé.
Il n'a pas de volumétrie spécifique a partir de laquelle partitionner devient nécessaire; cela dépend vraiment des usages. On parle cependant généralement d'1 milliard de lignes dans une table avant de songer a la partitionner (sauf besoin plus spécifiques liés aux fonctionnalités du partitionnement évidemment).
Bonjour,
Ce n'est malheureusement pas possible ni prévu pour le moment.
REGEXP n'est pas un operateur, du moins pas sur postgres (aucune idee sur d'autres moteurs). Soit votre cours est fait pour autre chose que postgres soit votre dis de remplacer REGEXP par quelquechose d'autre.
Bonjour,
Peut-être avez vous mal saisi les cours? Il vous manque l'opérateur d'expression régulière, et j'imagine que "REGEXP" devait à la base être substitué par l'expression elle même.
Pour résumer; vous devriez saisir :
WHERE numerotelephone ~ '^05'|'04$';
Voir https://www.postgresql.org/docs/current … SIX-REGEXP pour la documentation.
Bonjour,
Il s'agit d'un probleme classique. La solution habituelle est de positionner la ou les contraintes voulues en DEFERRABLE INITIALLY DEFERRED, cf https://www.postgresql.org/docs/current … aints.html
Peut-etre que ces 2 roles n'ont pas le meme search_path? \d ne renvoie que les tables qui sont visibles sans utiliser de schema (donc dans un schema present dans le search_path, et en cas de tables du meme nom seule la premiere sera affichee)
Oui c'est tout a fait possible, mais vous allez probablement avoir besoin de devlopper cette image vous-meme.
Bonjour,
De même avec \l, il n'y a pas la base de données créée
Vous n'avez pas montre de code creant une base de donnees.
SELECT * FROM demo.demo_table, je ne trouve rien.
Est-ce que le schema existe ? Est-ce que le SELECT * dans votre code retourne des donnees ?
Je ne connais pas PgMex, mais cela ressemble fortement a un probleme lie a PgMex qui creerait une transaction automatiquement (style autocommit desactive), et si vous ne la validez pas explicitement postgres effectuera un rollback lorsque vous coupez la connexion depuis votre applicatif. Vous devriez consulter la documentation de PgMex pour vous assurer de son comportement.
Bonjour,
Le message indique que psql n'a pas trouve d'instance pour essayer de tenter de s'authentifier. Cela peut vouloir dire que tout simplement les instances ne sont pas demarrees, ou le sont mais ecoutent sur un autre port, ou qu'un firewall bloque la connexion.
Il n'y a pas de raison pour qu'une partie des donnees disparaissent toutes seules. Avez-vous effectue des manipulations ou execute des commandes entre le crash du disque et le redemarrage avec des nouveaux binaires ?
C'est parce que createdb est un programme executable. La commande SQL correspondante est CREATE DATABASE, cf https://docs.postgresql.fr/16/sql-createdatabase.html
Bonjour,
Le raccourci que vous avez lance se nomme "SQL command (psql)", et sans surprise vous arrivez donc dans psql. Les commandes que vous avez lancees ne sont pas des commandes SQL mais des commandes systeme a lancer dans un terminal pour lancer psql ou effectuer diverses autres operations. De plus, psql est en attente de la validation d'une commande sql, c'est-a-dire un point virgule aui signifie la fin de la commande. Le plus simple est de fermer la fenetre et la reouvrir, et commencer ensuite avec des commandes SQL valides.
Si vous avez encore l'integralite des fichier du PGDATA il vous suffit de demarrer une instance en pointant vers ce repertoire et vous devriez avoir access a toutes les donnees. Vous pouvez copier les donnees vers un autre systeme ou reinstaller la meme version majeure de postgres sur la meme machine.
Cela devrait faire exactement ce que vous voulez, en supposant qu'il s'agit bien de la configuration qui a été appliquée.
Si seule la durée est affichée, sans le texte de la requête, alors c'est que vous avez activé log_duration.
La configuration actuelle provient du fichier postgresql.auto.conf, c'est-à-dire une configuration effectuée via ALTER SYSTEM. À noter que toute modification effectuée par ALTER SYSTEM est plus prioritaire qu'une simple modification dans le fichier postgresql.conf, il vous faut donc toujours effectuer des configuration via ALTER SYSTEM (ou jamais), mais ne pas mixer les deux. Cela dit, la configuration montre bien que la valeur de log_mi_duration_statements est à 1000 ms, soit 1 seconde. Peut être avez-vous également fait un ALTER SYSTEM pour logger toutes les requêtes (type log_statements = all) et avez essayé de remettre log_statements = none dans le postgresql.conf?
Si ce n'est pas le cas, avez-vous un exemple de ligne qui ne devrait pas se trouver dans les logs? Pouvez-vous également montrer le résultat de la commande "\drds" sur psql ?
Bonjour,
le JudeM vient effectivement de votre nom d'utilisateur système, qui est utilisé par défaut si vous ne précisez rien car il faut bien que postgres se connecte avec un nom d'utilisateur. Vous pouvez utiliser -U eclrest dans votre cas.
Concernant votre configuration, en supposant que la configuration ait été rechargée, la connexion sans mot de passe n'est possible que pour l'utilisateur eclrest (donc le -U est nécessaire), mais également uniquement en connextion "local", c'est-à-dire socket unix (qui sont supportées par windows depuis quelques temps). Il faut donc pointer vers cette socket. En supposant que la socket se trouve sur c:\la_socket il faudrait spécifier "dropdb -U eclrest -h c:\la_socket ocolis".
Si votre version de postgres et/ou de windows ne supporte pas les socket unix, vous pouvez configurer une ligne en trust pour une socket ip.
Je précise toutefois que même s'il s'agit d'une machine locale c'est en général une mauvaise idée de faire ça, vous pouvez toujours utiliser le fichier pgpass.conf pour stocker le mot de passe et ne pas avoir à le fournir explicitement à chaque fois (https://www.postgresql.org/docs/current … gpass.html), ou mettre en place une authentication via certificat (ou peer si vous avez bien une socket unix).
Bonjour,
À priori votre système reste à attendre que les connexions existantes soient coupées. Vous avez donc au moins une connexion qui reste bloquée, mais impossible de savoir pourquoi sans acces au serveur. Peut être utilisez-vous des extensions ou des fonctions dans un language "unsafe" qui font qu'une ou plusieurs connexions se retrouvent dans un état non interruptible. Le seul moyen de savoir serait de regarder la liste des processus quand le problème survient, et récupérer une backtrace du ou des processus encore en cours pour voir sur quoi ils sont bloqués.
Peu importe les commandes que j'exécute, je reçois systématiquement le même message d'erreur.
warning: extra command-line argument "psql" ignored
Quelle(s) commande(s) avec vous lancé ?
Le serveur fonctionne correctement, le chemin du socket est correct, les permissions du répertoire sont appropriées, et le serveur utilise le port correct (qui est correctement défini par défaut).
Comment vérifiez-vous que le serveur fonctionne et que le reste des informations est correct ?
Bonjour,
Avez-vous rechargé la configuraiton après avoir modifié le postgresql.conf? Si oui, que renvoie la requête
SELECT * FROM pg_settings WHERE name = 'log_min_duration_statement';