Vous n'êtes pas identifié(e).
Dans le cas où (auto)vacuum n'est pas effectué assez régulièrement la meilleure solution pour récupérer de l'espace est effectivement bien souvent vacuum full.
Un vacuum effectué de manière régulière permet bien de résoudre le problème, dans le sens où le bloat reste fixe plutôt que croitre continuellement, et la table à donc une volumétrie fixe (sauf évidemment s'il y a plus d'insertion que de suppression) ce qui semble être le problème ici.
Bonjour,
Les 3GB - 20 MB viennent-ils vraiment des modifications de quelques lignes chaque minute sur 3 tables ? Si oui cela voudrait dire une taille de plusieurs KB par enregistrement.
Quel système d'exploitation utilisez vous? Est-ce que vous lancez le script avec votre propre utilisateur ? Avez-vous vérifié les droits sur le fichiers (cf https://www.postgresql.org/docs/current … pass.html).
Si j'étais vous je partirais plutôt sur une approche basée sur l'automatisation d'un pg_dump / pg_restore plutôt que de la réplication logique, surtout si vous avez une bonne bonne passante entre les serveurs. Cela devrait être plus simple à mettre en place, et risque moins d'impacter votre serveur de production. La réplication logique est loin d'être gratuite : il faut redémarrer l'instance pour changer le niveau de WAL, les WAL générés sont plus volumineux, les grosses transactions sont assez couteuses à décoder et peuvent entraîner de nombreux problèmes, la syncronisation initiale est loin d'être rapide etc etc. Surtout qu'en plus vous avez en plus des tables relativement incompatibles avec la réplication logique (celles sans clé primaires).
Ce n'est toujours pas très clair. Voulez vous créer localement une base de données XXX_test à chaque fois depuis la base originale XXX, ou souhaitez-vous répliquer les données de chaque base vers 2 bases: une base identique et une base XXX_test ?
Bonjour,
Voulez-vous maintenir la réplication une fois les écritures activées sur le serveur de test?
À noter également que pgadmin4 à une notion d'utilisateur et mot de passe pour se connecter à pgAdmin lui-même, qui n'est pas la même chose que le role sur postgres et son mot de passe.
Bonjour,
le seul moyen est de redémarrer un postgres de la même version majeure sous windows pointant vers ce répertoire, faire une sauvegarde logique (pg_dump / pg_dumpall) et restaurer ça sur linux.
N'autoriser que la base en question pour l'utilisateur en question. Vous pouvez également faire ça au niveau de l'instance avec des REVOKE CONNECT ON DATABASE username FROM public; GRANT CONNECT ON DATABASE username TO username;
Bonjour,
Le répertoire ./UPDATE correspond-il a un tablespace, et plus précisément un tablespace stocké DANS le répertoire PGDATA (ou PGDATA/pg_tblspc)? Si c'est le cas, ce n'est pas officiellement supporté et tout problème résultant est sous votre responsabilité.
Bonjour,
Il n'y a aucun réglage à faire, la liste des bases de données est une information visible par n'importe quel utilisateur.
Si la base n'est pas affichée dans la liste des bases, c'est soit que la connexion pointe vers un autre serveur soit que pgadmin ne gère pas correctement les nom bases content un ".".
Vous pouvez vérifier avec un simple "SELECT * FROM pg_catalog.pg_database" si la base en question est présente ou non.
Bonjour,
Normalement la séquence sera inclue dans le dump si elle est déclarée comme dépendante de la table, donc du fait de cette commande:
ALTER SEQUENCE public.t0_id_seq OWNED BY public.t0.id;Vous pouvez vérifier dans la table pg_depend s'il existe une dépendance entre la séquence et une colonne de la table pour les cas où la séquence n'est pas inclue dans le dump d'une table.
Si je comprends votre problème n'a rien à avoir avec psql ni avec target_session_attrs, mais avec le fait que votre cluster "reste en vie" (du moins conserve le noeud restant en tant que leader) après la perte de 2 noeuds ?
Difficile de répondre sans connaître la configuration ni ce que vous faites exactement. J'imagine que si par exemple vous vous contentez d'arrêter postgres mais que patroni reste démarré il n'y a aucun problème pour conserver le dernier noeud en tant que leader car il n'y a pas de possibilité de split brain.
Je ne suis pas sûr de comprendre ce que vous cherchez à faire exactement.
Dans votre premier message vous disiez vouloir rester sur une connexion en écriture en cas d'interruption de la connexion, et maintenant vous dites vouloir l'inverse ?
pg_stat_statements accumule les diférentes métriques, il n'y a donc aucune notion de temps. Si par "statistiques d'hier" vous voulez dire "total de l'activité entre hier minuit et hier 23:59", le seul moyen pour avoir ces données est de procéder à des snapshots réguliers de pg_stat_statements et afficher le delta entre les 2 snapshots les plus proches de bornes voulues. Le projet powa fait exactement ça, pour pg_stat_statements et plusieurs autres sources de données : https://powa.readthedocs.io/en/latest/
Il y a quand même un identifiant pour chaque entrée de pg_stat_statements: (userid, dbid, queryid, toplevel). À noter que toplevel a été rajouté en version 14.
Il n'y a cependant aucune information concernant la date de création d'une entrée en particulier. Quel problème cherchez-vous à résoudre exactement ?
Il s'agit plutôt d'une limitation générale dans l'infrastructure de postgres. Pour l'instant, les seuls moyens de récupérer un min() ou max() sont:
- renvoyer les donneés triées dans l'ordre voulu et s'arrêter une fois une valeur trouvée
- lire toutes les données et conserver la valeur maximum trouvée
La première approche n'est intéressante que si on peut retourner les données triées dans l'ordre voulu, ce qui n'est le cas que pour un index btree.
Utiliser un index brin pour récupérer la valeur max sans lire toutes les données de la table serait théoriquement possible, mais nécessiterait de développer un nouveau mode d'exécution. Comme discuté dans le thread pointé par pifor, le problème est également plus complexe qu'il ne parait car les valeurs min/max stockées dans l'index brin ne sont pas maintenues, et il n'y a aucune garanties que ces valeurs soient toujours visible, ou simplement visible par la requête en cours d'exécution. Cela veut dire la nécessité d'avoir une approche récursive dans le cas où les ranges choisis ne contiennent aucune valeur supposées être présentes uniquement dans ceux-ci. Dans des cas extrêmes le temps d'exécution pourrait devenir bien pire que lire toutes les données séquentiellement (potentiellement avec des workers parallèles). À noter qu'il n'y a pour l'instant aucune statistique qui pourrait aider à décider si ce type de parcours serait intéressant ou non. Le cumul de tout ça explique probablement pourquoi personne n'est intéressé pour travailler sur le sujet.
La sauvegarde, mais également la restauration, gestion de la rétention etc est un sujet complexe et avoir une commande sous la main ne répondra pas à ceux-ci, surtout sans savoir quels sont vos besoin exactement.
Vous pouvez consulter la documentation à https://www.postgresql.org/docs/current/backup.html pour un aperçu des possibilité de sauvegarde/restauration, et vous avez une liste d'outil associés disponible à https://wiki.postgresql.org/wiki/Ecosystem:Backup
Mais lors de la connexion avec psql on me demande le mot de passe de berou qui est le nom de mon compte sur ma machine.
et là j'ai quelque soit ma saisie un refus :Mot de passe pour l'utilisateur berou :
psql: erreur : la connexion au serveur sur « localhost » (::1), port 5432 a échoué : FATAL: authentification par mot de passe échouée pour l'utilisateur « berou »
psql se connecte par défaut avec le nom du rôle correspondant au nom d'utilisateur côté système d'exploitation, donc "berou" dans votre cas. Vous devriez essayer "psql -U postgres", s'il s'agit du compté créé par l'installeur que vous utilisez. Sinon, vous pouvez consulter https://docs.postgresql.fr/16/auth-pg-hba-conf.html pour configurer postgres sans avoir besoin de saisir de mot de passe le temps de créer le(s) rôles nécessaire(s) et/ou modifier les mots de passe.
Bonjour,
Difficile de vous aider sans plus de détails sur ce que vous avez fait ainsi que le(s) messages d'erreur.
Cela étant dit, si vous n'avez récupéré que le contenu du répertoire base/, il est impossible de repartir de cela. Il vous faut l'intégralité du répertoire parent, tous les tablespaces si vous en avez ainsi que le contenu du répertoire pg_wal/pg_xlog si celui-ci est stocké ailleurs.
Concernant pg_upgrade, cela nécessite les 2 versions des binaires présentes, ainsi que les données présentes localement. Le reste est libre, sous réserve de ne pas faire de changement d'architecture (32 <-> 64 bits, Windows <-> Linux, Big Endian <-> Little Endian etc), mais pg_upgrade vous prévient avant en cas de problème. Rien ne vous empêche de ruser pour limiter le temps pour avoir la dernière versions des données sur le nouveau serveur (restaurer une sauvegarde puis appliquer les WAL depuis le serveur principal, faire un rsync une fois le serveur principal éteint...).
La grosse limitation concerne les versions de la libc / ICU. En cas de version différentes, il est possible (voire probable en fonction des versions présentes et des collations utilisées) que les index portant sur des données collationnables soient corrompues. La solution consiste à faire un reindex de tous les index index impactés, mais même faire un pg_upgrade puis réindexer tous les index (puis faire le vacuum/analyze préconisé par pg_upgrade) devrait être beaucoup moins long que tout restaurer à coup de pg_dump / pg_restore.
La partie ALTER SYSTEM est géré via https://github.com/postgres/postgres/bl … uc.c#L4450. La lecture du fichier généré se trouve probablement dans le même fichier, sinon il faut fouiller.
J'imagine que vos machine ont 8GB de RAM et non 8MO 
Pour le reste, cela dépend grandement de comment tout est configuré. S'agit-il d'une restauration en parallèle ? Y a-t-il des slots de réplications ? En cas de problème, vous aurez à choisir entre ralentir la restauration, sacrifier le serveur secondaire (cad devoir le resynchroniser de 0 plus tard) ou sacrifier le serveur primaire (cad le voir finir en arrêt brutal pour cause de manque d'espace disque dans le répertoire pg_wal). À vous de voir ce qui vous convient le mieux.
Pourquoi ne pas utiliser pg_upgrade pour la montée de versions, à partir d'un réplicat physique / pg_basebackup. Cela devrait être bien plus efficace qu'un pg_dump/pg_restore.
"So basically avoid to modify it manually as this is used for ALTER SYSTEM. When a parameter is modified, a temporary file called postgresql.auto.conf.temp is created to rollback to the original state in case of error."
Quel est l'empleur du mot "basically"? juste pour la forme!? ou il y a vraiment une contrainte technique?
La signification est "n'y touchez pas sous risque de casser quelque chose". Si vous avez lu tout le code source de postgres en rapport à ce fichier et tout compris, vous pouvez évidemment modifier le fichier selon ce que vous voulez faire mais si vous tentez un rapport de bug commençant par "j'ai modifié le fichier qui commence par merci de ne pas modifier ce fichier", personne ne daignera répondre.
1- Est ce que le comportement était toujours comme ceci ou il a changé pour ce fichier de configuration "postgresql.auto.conf".
2- A quel moment le fichier "postgresql.auto.conf.temp" apparait, car je n'ai pas pu mettre la main dessus ( comment faire un test correctement pour le voir?).
3- Hormis l'aspect interactif du changement des paramètres journalisés dans ce fichier quel est le plus par rapport aux paramètres (include_dir, include et include_if_exists)?
4- la mise en garde au début du fichier (Do not édit....), c'est pourquoi à votre avis?
1- j'imagine que le comportement a toujours été le même, mais cela n'a pas d'importance. Ne le modifiez pas manuellement sauf si vous savez ce que vous faites.
2- il apparait de manière temporaire afin de garantir la durabilité du fichier. C'est un détail d'implémentation que vous pouvez ignorer.
3- Cela n'a aucun rapport avec les possibiligés d'inclusion d'autre fichier. C'est un mode de configuration via sql qui aura la priorité, tel que documenté.
4- tout modifications pourrait "casser" ALTER SYSTEM. Encore une fois n'y touchez pas manuellement.
J'ai copié le fichier pyhton310.dll dans mon chemin C:\Windows\System32 afin que de pouvoir créer l'extension.
Je ne suis pas utilisateur de Windows mais je suis à peu près sûr que la bonne façon de faire est de configurer le PATH ou autre variable, soit global soit pour l'utilisateur démarrant le service postgres, afin que le répertoire où python est installé soit visible. Sans ça vous n'aurez qu'une partie de python disponible et de nombreuses erreurs assez bizarres, telles que ce que vous montrez ici.