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 : Réplication » Le server construit en réplication refuse de démarer » 01/10/2021 06:26:27

De ce que je vois la timeline 2 existe et a été trouvée, mais la sauvegarde ne correspond pas cet historique.


J'ai l'impression que la restore_command récupère les mauvais fichiers, ou que le serveur source a été promu puis repassé en timeline 1.

#2 Re : PL/pgSQL » Conditions dans loop » 28/09/2021 13:16:00

Bonjour


Mais ça remplace toutes les routes remplissant cette condition.

Quelle condition exactement?  Vous n'avez aucune clause where donc la mise à jour va s'effectuer sur toutes les lignes, que le contenu change ou non.


Savez-vous comment faire ?


Utiliser ce CASE dans votre SET "ROUTE" ne fonctionne pas ?  Quelle est l'erreur ?

#3 Re : Général » Le rôle n'existe pas... bien qu'il existe » 23/09/2021 03:58:14

Le logiciel force l'utilisateur de connexion?  Cela me semble un bien mauvaise idée mais soit.



Le problème vient bien de l'encodage, il faudrait savoir quel est l'encodage utilisé soit par odoo soit par windows pour votre user.  Peut être que copier/coller le nom d'utilisateur depuis les logs suffirait créer le bon rôle.

#4 Re : Général » Create domain » 21/09/2021 19:31:39

Bonjour,


Non les domaines sont des objets locaux à une base spécifiques, vous devez donc les recréer sur chacunes des bases où vous souhaitez l'utiliser.  Vous pouvez cependant encapsuler vos objets dans une extensions pour faciliter le déploiements sur de nombreuses bases.

#5 Re : PL/pgSQL » résultat requête vers noms de colonnes » 16/09/2021 03:48:42

Il manque des informations sur ce que vous cherchez à faire exactement.  Si vous voulez faire une requête spécifique sur des tables dont la structure est fixe (et donc modifier la requête en cas de changement de schéma), cela reste possible en sql.  Par exemple:


select tab1.ctxt, tab2.esp,
    case
        when tab1.biotypo = 'b1' then tab2.b1
        when tab1.biotypo = 'b2.5' then tab2."b2.5"
        when tab1.biotypo = 'b3' then tab2.b3
    end as bio
from tab1
join tab2 on
    case
        when tab1.biotypo = 'b1' then tab2.b1 is not null
        when tab1.biotypo = 'b2.5' then tab2."b2.5" is not null
        when tab1.biotypo = 'b3' then tab2.b3 is not null
    end;

Veuillez noter que cette requête ne s'assure absolument pas que les données dans tab1 sont valides, et retournerait donc un peu n'importe quoi dans le cas où tab1.biotypo est invalide.  C'est quelque chos que vous auriez à corriger, l'idée étant de simplement donner une approche qui pourrait marcher.


Veuillez noter également que les performances risquent d'être désastreuses dans le cas où beaucoup de données doivent être retournées.  Vous pourriez probablement avoir de meilleures performances avec une approche à base de UNION ALL, avec une requête par "biotypo", mais en contrepartie vous auriez de mauvaise performance dans le cas où une clause WHERE excluerait la majorité des enregistrements.


Tous ces problèmes sont dû au format de stockage de vos données.

#6 Re : Général » fichier pour tester la connexion vers un serveur postgres » 16/09/2021 03:27:52

Si vous ne cherchez qu'à savoir si une instance est joignable, vous pouvez utiliser l'outil client pg_isready: https://www.postgresql.org/docs/current … ready.html.


Si vous voulez valider qu'une authentification est possible, il vous faudra utiliser un vrai client, que ce soit psql ou un autre.

#7 Re : Général » [Résolu] PgAdmin4 erreur de mot de passe. » 06/09/2021 18:07:09

Si vous n'avez qu'une instance locale, c'est que votre identifiant/mot de passe pour votre role postgres est faux.  Qu'entendez-vous exactement par "connexion en mode root", et comment validez vous que cette connexion fonctionne ?


Les logs de postgres devraient donner plus de détails, notammetnt le nom du role postgres pour lequel la connexion a échouée avec pgAdmin.

#8 Re : Général » [Résolu] PgAdmin4 erreur de mot de passe. » 06/09/2021 03:46:51

Bonjour,


Je n'utilise pas pgAdmin 4 mais à priori ce sont des erreurs de connexion à postgres, pas à pgAdmin.

#9 Re : Général » Sauvegarde serveur automatique » 02/09/2021 04:34:14

Bonjour,



Je ne suis pas certain de comprendre votre problème.  Vous avez une production qui se base sur docker, avez-vous les compétences pour créer une image docker afin d'utiliser le ou les outils de votre choix ?  Si oui, pourquoi ne pas créer vous même une image docker pour un des outils listés sur la page wiki?  Si ce n'est pas le cas, et si vous n'avez pas la possibilité d'acquérir cette compétence, je pense qu'utiliser docker est une mauvaise idée.

#10 Re : Général » Sauvegarde serveur automatique » 25/08/2021 09:05:22

Je n'ai jamais entendu parler de cette image.  Je ne sais pas où sont les sources, mais après une rapide lecture de https://hub.docker.com/layers/prodriges … xt=explore (qui est totalemebt illisible malheureusement), je crois que cette image est supposée servir à la fois d'instance postgres et de sauvegarde sur cette instance.



Cela me semble une mauvaise idée, car vous avez déjà votre image docker qui tourne, et même si ce n'était pas le cas postgres est trop critique pour se reposer sur une image non officielle.


De plus, il s'agit de sauvegarde logique (type pg_dump).  N'ayant pas la source, difficile de juger du contenu mais il est par exemple possible que les roles et/ou tablespace ne soient pas sauvegardés par exemple.  De plus, une sauvegarde logique est vite limitante et il est généralement préférable d'utiliser des sauvegardes physiques (type PITR).


Je vous déconseille donc l'utilisation de cette image, qui à packager vous même un des outils de sauvegarde physique.

#11 Re : Général » Sauvegarde serveur automatique » 25/08/2021 06:11:00

Il y a différentes solutions de sauvegarde présentées ici : https://wiki.postgresql.org/wiki/Ecosystem:Backup

Vous pouvez consulter leurs documentations et voir ce qui correspond à votre besoin, notamment la possibilité de l'intégrer facilement dans un environnement docker.

#12 Re : Optimisation » ordonnancement pg_squeeze » 17/08/2021 16:28:41

Tout d'abord, quand je parle de "contrôler la fragmentation" je ne veux dire d'essayer d'avoir 0% de bloat à tout prix.  C'est relativement impossible et c'est de toutes façons une mauvaise idée : certaines optimisations existent pour profiter de cette fragmentation.  Ce que je veux dire c'est de faire en sorte d'avoir une fragmentation relativement stable.  Avoir 1% de bloat, 10% ou même 30% n'est pas un problème en soi, le problème est d'avoir une quantité de fragmentation qui continue toujours à augmenter.  Et c'est ça qu'il faut corriger.


Dans votre cas (au passage des insertions n'entrainent pas de fragmentation), si vous avez de la fragmentation à cause de batch de modifications, la solution est probablement d'effectuer un VACUUM juste après ces batchs, ou après les batch les plus volumineux.  Vous aurez certes de l'espace perdus suite à ces bachs, mais l'espace sera presque immédiatement réutilisable, et vous fonctionnerez donc avec une sorte de "circuit fermé" avec vos X% de fragmentation, qui devrait à priori correspondre à la quantité de modification effectuée par votre plus grand batch, ou votre plus grande série de batch, en fonction de ce que vous faites.


Le seul problème serait si vous avez une table gigantesque, et un de vos batch supprime une grande partie des données (mais pas suffisamment pour rendre un VACUUM FULL presque immédiate par exemple), ou réécrit l'intégralité des données ou presque.  Dans ce cas effectivement vous pourrez garder un bloat sous controle, mais il sera pourra représenter un espace de stockage trop important pour que de futures écritures réutilisent l'espace avant de longs mois voire années.  Dans ce cas, le seul moyen est effectivement de trouver un compromis acceptable (découper le batch en plusieurs transaction et effectuer des vacuums au milieu, utiliser du partitionnement pour supprimer des tables plutôt que des lignes...).

#13 Re : Optimisation » ordonnancement pg_squeeze » 17/08/2021 10:22:44

Il faut idéalement éviter le besoin de défragmenter, c'est-à-dire :


1) chercher la ou les tables fragmentées
2) chercher pourquoi la fragmentation arrive, à quelle fréquence etc
3) faire en sorte que la fragmentation reste sous controle


C'est difficile d'aller plus dans le détail vu que l'étape 3) dépend de l'étape 2), et l'étape 2) peut être causée par tellement de chose.  Il existe probablement des cas pathologiques ou la fragmentation ne peut pas être évitée et où faire un vacuum full (ou équivalent) est obligatoire, mais je n'en ai personnellement jamais rencontré.  Par contre des cas où éviter de la fragmentation implique des modifications plus ou moins importante dans le code client, c'est fréquent.

#14 Re : Optimisation » ordonnancement pg_squeeze » 17/08/2021 09:16:21

Je ne pense pas utiliser un jour cette extension en production.  pg_repack avait (et a toujours) un bug sur le freeze pouvant corrompre les données, et après une rapide vérification je n'ai aucune confiance sur la gestion de cette partie dans cette extension.  Cf https://github.com/cybertec-postgresql/ … 3124-L3297


Je note particulièrement que le commentaire de la fonction mentionne :

* XXX Unlike PG core, we currently receive neither frozenXid nor cutoffMulti
* arguments. Instead we only copy these fields from r2 to r1. This should
* change if we preform regular rewrite instead of INSERT INTO ... SELECT ...


alors que le code fait autre chose :

	/*
	 * Set rel1's frozen Xid and minimum MultiXid.
	 */
	if (relform1->relkind != RELKIND_INDEX)
	{
		TransactionId frozenXid;
		MultiXactId cutoffMulti;

		frozenXid = RecentXmin;
		Assert(TransactionIdIsNormal(frozenXid));

		/*
		 * Unlike CLUSTER command (see copy_heap_data()), we don't derive the
		 * new value from any freeze-related configuration parameters, so
		 * there should be no way to see the value go backwards.
		 */
		Assert(!TransactionIdPrecedes(frozenXid, relform2->relfrozenxid));
		relform1->relfrozenxid = frozenXid;

		cutoffMulti = GetOldestMultiXactId();
		Assert(MultiXactIdIsValid(cutoffMulti));
		Assert(!MultiXactIdPrecedes(cutoffMulti, relform2->relminmxid));
		relform1->relminmxid = cutoffMulti;
	}

Je n'ai pas cherché à savoir si cela vient d'une modification dans postgres ou de cette extension, mais c'est un point particulièrement critique et il n'y a aucun commentaire expliquant pourquoi cette approche est correcte.  Surtout si le code provient de CLUSTER, qui détient un verrou exclusif durant toute l'opération, alors que cette extension n'a pas du tout le même verrouillage.


Bref, personnellement je n'ai pas confiance dans cette extension et si j'étais confronté à un problème de bloat excessif je chercherais plutôt un moyen d'éviter l'apparation de bloat trop important plutôt que risquer une corruption ou perte de données.

#15 Re : Optimisation » ordonnancement pg_squeeze » 16/08/2021 18:46:12

Bonjour,


Pour ma part c'est la première fois que j'entends parler de cette extension.  À votre place j'ouvrirais une issue sur le dépot github.

#16 Re : Général » error absence du relation pg_restore » 16/08/2021 02:42:12

C'est impossible.  Contrairement à d'autres moteurs, postgres n'autorise pas la création d'objets invalides.

#17 Re : Général » Probléme de démarage du service postgresql » 14/08/2021 07:05:02

Le message me semble clair :

échec de la connexion à la base de données : fe_sendauth: no password supplied


Vous devez faire en sorte de pouvoir vous connecter sur l'instance, que ce soit en changeant le pg_hba.conf ou en modifiant votre fichier pgpass ou tout autre moyen de connexion utilisé.

#18 Re : Général » Probléme de démarage du service postgresql » 13/08/2021 15:08:03

Quelles étaient les erreurs retournées par pg_upgrade?

#19 Re : Général » Changer le chemin du repertoire data (windows serveur 2019) » 13/08/2021 08:31:59

Si cela ne suffit pas à résoudre le problème, il faudra le contenu des logs (soit logs postgres soit observateur d'evenements) pour donner plus de détails.

#20 Re : Général » Probléme de démarage du service postgresql » 13/08/2021 07:11:59

Bonjour,


L'erreur survient à quel moment exactement ?

#21 Re : Général » taille base de base de donnée Different aprés pg_restore » 09/08/2021 04:44:31

samirca007 a écrit :

Est ce que ces error sont redirigé vers le dossier pg_log ?

car j'ai fermé la fenétre du restoration

Cela dépend des erreurs.  Il va vous falloir vérifier si vous trouvez 663 erreurs dans les logs au moment de la restauration.

#22 Re : Général » taille base de base de donnée Different aprés pg_restore » 08/08/2021 19:23:56

C'est normal que la taille diminue, une restauration logique va supprimer le bloat.

Par contre :

pg_restore: warning: errors ignored on restore: 663

663 erreurs, c'est inquiétant.  Consulter la liste des erreurs mentionnées et vous saurez s'il vous manque des données.

#23 Re : Général » pg_restore avec l'option -j » 08/08/2021 06:48:31

Utilisez le nombre de core sur votre machine.

#24 Re : Installation » Déplacer ou créernouvelle base de données dans un dossier personnel » 07/08/2021 11:22:47

Bonjour,


Je pense que postgres n'est pas forcément le meilleur outil pour votre besoin.  Je pense qu'il est possible de faire en sorte d'avoir une instance postgres démarrée dans votre home, mais vous allez devoir faire de nombreuses modifications car cela va un peu à l'encontre du fontionnement par défaut (debian est une distribution orientée serveur).


Je vous recommanderais plutôt d'utiliser quelquechose comme sqlite qui est fait pour ça.  Si vous tenez vraiment à utiliser postgres, il vous faudra consulter la documentation de postgres ainsi que des wrappers debian (par exemple https://manpages.debian.org/experimenta … 1.en.html) pour adapter le fonctionnement à votre besoin, et cela risque de prendre un certain temps pour réussir à tout faire fonctionner.


Cela dit, je ne suis pas certain de comprendre votre prérequis.  Vous ne devriez pas avoir à accéder aux fichiers sous jacents, sauf besoin de sauvegarde / restauration, et l'emplacement de ces fichiers dans votre /home n'a que peu d'importance, du moment que vous configurez votre outil de sauvegarde correctement.  S'il s'agit d'un problème d'espace disque, utiliser lvm devrait vous permettre de dimensionner différents systèmes de fichiers de manière plus souple.

#25 Re : Général » Backup /restore database postgis » 06/08/2021 06:15:11

Qu'entendez-vous par base de configuration exactement ?  Si la base contient vos données de configuration il faut à priori la migrer également.

Pied de page des forums

Propulsé par FluxBB