Vous n'êtes pas identifié(e).
Il faudrait un EXPLAIN (ANALYZE, BUFFERS) de la requete pour chacun des plans idealement (sinon seulement pour la version qui effectue un hash anti join) pour comprendre l'origine du probleme. La cause la plus probable est aue le parcours de gd_coordonnee retourne bien plus de lignes que prevu, ce qui fait exploser le temps d'execution de la requete avec un nested loop de maniere proportionnel.
Bonjour,
La vue systeme pg_stat_database contient les colonnes blks_read (blocks lu en dehors du shared_buffers) et blks_hit (blocs lu dans le shared_buffers).
Bonjour,
Le plus simple est de proceder a un pg_upgrade du serveur primaire puis de reconstruire le serveur secondaire a partir du primaire que vous avez mis a jour. Si cela depasse le temps d'interruption possible vous aller devoir choisir une autre technique plus compliquee mais qui limite le temps d'interruption.
Naivement je vous conseillerais de simplement chiffrer le disque ou sont stockees les donnees.
Si cette solution m'est pas suffisante, vous devriez decrire quels sont les vecteurs d'attaque dont vous voulez vous proteger.
Est-ce que vous executiez
c:\Users\user>psql -U postgres -d sqlda -f data.dumpou
psql -U postgres -d sqlda -f data.dumpavec l'invite de commande dans le repertoire "c:\Users\user"?
psql -U postgres -d sqlda -f data.dump
et la le curseur clignote sur place rien se passe...
Comment savez-vous que rien ne se passe ? Est-ce que la commande met simplement du temps a s'executer ou avew vous verifie sur votre instance qu'il n'y a aucune activite ?
Vous pourriez essayer https://github.com/dbcli/pgcli, cela devrait fonctionner à l'identique sous windows.
Il n'y a à ma connaissance aucun moyen d'avoir une complétion sous windows, car la complétion n'est possible qu'avec la libreadline mais windows ne fournit que la libedit qui n'a pas cette fonctionnalité.
Il n'y a pas de "\Users" dans le fichier. Quelle commande avez-vous effectue exactement ?
D'ou provient le fichier data.dump?
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