Vous n'êtes pas identifié(e).
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';
Ce n'est pas possible dans postgres, mais si vous tenez vraiment à la sécurité il faut le faire côté client. Pour pgAdmin, je ne sais pas si la fonctionnalité existe, mais je serais surpris que cela soit le cas.
Bonjour,
Quel est l'écart entre les 2 approches ?
Le problème ne vient pas forcément du fait que vous utilisez une boucle while, même si le langage plpgsql n'a jamais été écrit pour être très rapide, mais plutôt du fait que chaque itération à un surcout assez impressionnant du fait que vous créez, supprimez et renommez des tables à chaque itération. Même si vous pouviez rendre cette fonction plus rapide, je vous déconseillerai de l'utiliser car elle aurait d'autres problèmes, notamment une fragmentation excessive des catalogues systèmes.
Le problème vient de là. Vous pouvez consulter la documentation pour plus de détail et les possibilités pour éviter ce problème: https://www.postgresql.org/docs/current … -REMOVEIPC
La plupart des gens utilisent des outils type ansible, ou passent par une fonctionnalité propre à leur environnement (du type migrations django etc). Aucune modification manuelle, aucun risque d'oubli.
Le problème est uniquement lié à un trop grand nombre de verrous nécessaires, changer le shared_buffers n'aidera pas.
Je précise également que le problème ici n'est pas exactement la taille de la base, du moins pas la taille sur disque, mais le nombre d'objets à sauvegarder. La base pourrait être miniscule, par exemple si toutes les tables sont vides, et toujours nécessiter des centaines de milliers de verrous si vous aviez un très grand nombre de tables. Utiliser la sauvegarde physique / PITR permet de ne pas dépendre de max_locks_per_transaction.
Si le service n'est vraiment pas démarré (il est important de vraiment s'en assurer), supprimer les fichiers postmaster.* pourrait résoudre le problème.
Bonjour,
Avez-vous vérifié dans pg_stat_activity / pg_locks si pg_dump était bloqué par une autre requête? En effet pg_dump commence par acquérir un verrou de type AccessShareLock sur chacun des objets de la base sauvegardée, donc si vous avez une transaction ouverte qui contient un verrou exclusif sur un des objets pg_dump sera en attente jusqu'à la fin de cette transaction.
Au dela de ce problème, avez-vous considéré l'utilisation de sauvegarde PITR? Les sauvegardes logiques ont de nombreuses limitations (pas de possibilité de restaurer à un point après le début du pg_dump, lenteur de restauration etc).
Le fichier contient la valeur 15 seulement.
Et dans /var/lib/postgresql j'ai seulement le dossier nommé 15.
C'est donc effectivement les données d'une instance en version 15. Si vous utilisiez postgres 13 auparavant, je ne sais pas ce qu'il s'est passé mais vos données ne sont plus là. Ou peut être avez-vous effectué un pg_upgrade (ou pg_upgradecluster, il me semble que le packaging debian fournit un wrapper pour cela)?
La plupart des noms des paquets ne terminent ni avec debXXX ni avec pgdgXXX.
Par contre certains finissent par debXXX et aucun ne finit par pgdgXXX.
Ok, donc vous avez les paquets debian.
Pour en revenir à votre problème original, je ne vois pas trop comment aider sans avoir plus de logs. Peut-être pouvez vous essayer de démarrer postgres avec pg_ctlcluster, ou directement avec pg_ctl et obtenir les logs manquants? Vous pouvez sinon vérifier la configuration de postgres pour vous asurer que les logs vont bien dans le répertoire en question et que les droits sur ce répertoire sont ok, ou la documentation des paquets debian pour savoir où se trouvent les logs qui surviennent dans ce genre de situation.
pg13
Si vous utilisiez pg13 avant la mise à jour de Debian et que pg_lsclusters indique maintenant une unique instance avec pg15, vous avez à priori un gros problème.
Juste au cas où, que contient le fichier /var/lib/postgresql/15/main/PG_VERSION ? Avez-vous d'autres répertoires dans le répertoire /var/lib/postgresql/ ?
Bonne question... ça fait longtemps que je l'ai installé, me souviens plus trop. y'a un moyen de le savoir ?
Vous pouvez faire un "apt list | grep postgres". Si les noms des paquets finissent avec "...+debXXX" ils proviennent du repo de debian, sinon ils devraient finir avec "+pgdgXXX" pour le repo du pgdg.
Que vous dit pg_lsclusters? Utilisiez vous pg15 ou pg13 avant la mise à jour de debian? De pus, utilisez vous les paquets de debian ou du pgdg?
Le fichier de pid est créé par postgres lors du démarrage, son absence indique donc sans surprise un problème de démarrage. Vous pouvez vérifier à tout hasard si le /run/postgresql/ existe bien et est accessible par postgres, mais si ce n'était pas le cas il devrait y avoir des info dans les logs.
Peut-être avez-vous un autre fichier de log, type startup.log, pour ce qui pourrait être généré avant que postgres ne démarre le log collector (si c'est ce que vous utilisez). Sinon peut être que journalctl (ou ce que vous utilisez) à plus d'informations ?
Bonjour,
Il devrait y avoir plus d'info dans les logs de postgres plutôt que les logs du service, pouvez-vous nous montrer le contenu de ceux-ci ?
Faites le calcul de combien d'espace vous pouvez vous permettre pour la fragmentation, et configurez l'autovacuum sur la table pour se déclencher après le nombre moyen et/ou ratio moyen de mise à jour faites pour atteindre cette volumétrie.
Vous ne pourrez jamais avoir une absence totale de fragmentation, et essayer d'avoir l'autovacuum qui se déclenche en permanence sur ces tables gacherait vos ressources pour un gain assez faible en espace disque.
Au bout de combien de temps la table grossit-elle de 200 or 400MB, j'imagine que ce n'est pas en 1 minute ? La volumétrie est-elle dans la table elle même ou la table TOAST associée ?
Comment avez-vous installé postgres? Est-ce un serveur sous linus avec systemd, et avec un utilisateur faisant tourner postgres ayant un uid > 1000 ?
Un VACUUM FULL nécessite un verrou exclusif sur la table, et bloque bien toute opération concurrente dessus.
Concernant autovacuum, en supposant qu'il n'est pas désactivé de manière globale, il devrait se déclancher après la modification d'un nombre de ligne égal à 20% du nombre de ligne total dans la table (le autovacuum_vacuum_scale_factor à 0.2) + 1 (le autovacuum_vacuum_threshold). Vous êtes le seul à avoir accès à vos données et à la charge en modification, à vous de modifier ces paramètres pour faire en sorte qu'autovacuum se déclenche à une fréquence suffisante pour éviter que la fragmentation n'explose (sans faire en sorte qu'il se déclenche après chaque modification, avoir un peu de bloat est normal et peut même être utile car cela permet de bénéficier des mise à jour HOT).
