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 : Migration » [Résolu] Migration MS Access vers Postgresql - Caractères CR/LF » 25/02/2024 19:50:37

Les + et espaces ne sont que de la mise en page de psql (vous devez être dans le mode étendu). Ils ne sont pas en base.

Sinon si c'est pour copier d'une base access vers postgres, vous pouvez aussi demander à access de vous produire un CSV. COPY peut importer le format CSV directement, et vous serez sûr de garder vos caractères supplémentaires

#2 Re : Migration » [Résolu] Migration MS Access vers Postgresql - Caractères CR/LF » 25/02/2024 15:55:00

Bonjour,
Puisque c'est pour injecter dans un COPY, le plus simple, c'est de remplacer CR par \r et LF par \n. cf paragraphe "Text Format" dans https://www.postgresql.org/docs/current/sql-copy.html

#3 Re : Réplication » Switchover sans perte de données » 16/01/2024 18:16:41

gleu a écrit :

* est-il possible de faire en sorte que le primaire stoppe si le standby est déconnecté?

Automatiquement non. Il vous faut un script qui arrête le secondaire une fois qu'il a détecté la déconnexion du secondaire.

Par contre suivant le besoin, une répli synchrone pourrait amener le résultat souhaité… vu qu'on ne peut plus écrire sur le primaire si le standby est déconnecté

#4 Re : Général » Génération de WALs même avec wal_level=minimal » 30/11/2023 19:11:15

En fait ça tombe plutôt bien, on est en plein dans un des cas que wal_level=minimal permet d'optimiser. Si vous mettez le CREATE TABLE et les deux inserts dans la même transaction, là vous ne générerez pas de WAL avec wal_level=minimal. Parce que simplement vérifier que la table est écrite sur le disque à la fin de la transaction (un sync des fichiers qui la composent) suffit (si PG crashait entre temps, il suffirait d'effacer ces fichiers au redémarrage).

Mais en vrai, il y a peu de cas où on gagne vraiment avec minimal. Il faut vraiment connaître ces quelques cas particuliers pour en profiter

#5 Re : Général » Optimisation de l'export Postgresql sur une base de 100Go » 09/08/2023 11:29:15

Vous pouvez essayer l'option -j de pg_dump, pour paralléliser le dump (plusieurs tables en parallèle). Vous n'aurez de gros gains avec cette méthode que si vous quelque chose de parallélisable évidemment, donc pas une grosse table unique dans la base.

#6 Re : Général » partitionnement, copy et ressource : » 24/01/2023 14:58:30

Il me semble oui, mais regardez la doc sur ALTER TABLE, c'est assez détaillé

#7 Re : Site PostgreSQL.fr » Comment ecrire une requete SQL sur deux tables differentes » 24/01/2023 12:36:42

exactement. C'est le critère qui met en correspondance les enregistrements des deux tables.

#8 Re : Site PostgreSQL.fr » Comment ecrire une requete SQL sur deux tables differentes » 24/01/2023 12:18:41

Le select 1 est en fait juste une "astuce" d'écriture. Le not exists vérifie juste que la sous-requête retourne un enregistrement. Son contenu n'a absolument aucune importance. J'ai pris l'habitude de l'écrire comme ça parce que pour le relecteur éventuel de la requête, c'est comme ça évident que le contenu de la sous-requête ne sert à rien. Ça pourrait être select 0 ou select 'toto' ça marcherait exactement pareil

#9 Re : Général » partitionnement, copy et ressource : » 24/01/2023 10:14:25

Vous avez tous les index qui doivent être là sur la partition finale ? Comme le dit la doc, "This form attaches an existing table (which might itself be partitioned) as a partition of the target table. The table can be attached as a partition for specific values using FOR VALUES or as a default partition by using DEFAULT. For each index in the target table, a corresponding one will be created in the attached table; or, if an equivalent index already exists, it will be attached to the target table's index, as if ALTER INDEX ATTACH PARTITION had been executed". Donc si il manque des index, ils vont être créés au moment de l'ALTER TABLE, alors que vous pourriez les avoir pré-créés (éventuellement en CONCURRENTLY, je ne connais pas votre cas d'utilisation).
Il peut aussi se retrouver à faire une vérification de votre "FOR VALUES" si il n'y a pas de contrainte CHECK sur la partition au moment de l'ATTACH: "If the new partition is a regular table, a full table scan is performed to check that existing rows in the table do not violate the partition constraint. It is possible to avoid this scan by adding a valid CHECK constraint to the table that allows only rows satisfying the desired partition constraint before running this command. The CHECK constraint will be used to determine that the table need not be scanned to validate the partition constraint. This does not work, however, if any of the partition keys is an expression and the partition does not accept NULL values. If attaching a list partition that will not accept NULL values, also add NOT NULL constraint to the partition key column, unless it's an expression."

#10 Re : Site PostgreSQL.fr » Comment ecrire une requete SQL sur deux tables differentes » 24/01/2023 09:51:56

Ou un NOT EXISTS si c'est simplement pour un test d'existence. le NOT IN est plus dangereux: il peut y avoir des NULL dans la seconde liste, alors il y a des optimisations qui pourraient ne pas être faisables. Le LEFT JOIN risque de vous dupliquer les enregistrements s'ii y en a plus d'un qui correspond

Quelque chose du genre

SELECT * from t1 where NOT EXISTS (SELECT 1 FROM t2 where t1.a=t2.a)

#11 Re : Général » authentification » 16/01/2023 20:38:20

Ça a l'air bon. Vous êtes sûr de votre mot de passe ? Sinon, vérifiez aussi qu'il est bien stocké en scram et pas en md5 dans le catalogue (regardez dans pg_shadow, si le champ passwd commence bien par SCRAM)

#12 Re : Général » authentification » 16/01/2023 17:50:00

Je ne connais pas R. Par contre le message d'erreur, c'est la librairie libpq (celle qu'on utilise à peu près tous, en C) qui vous dit que l'authentification par mot de passe (donc dans le fichier pg_hba.conf une ligne password, md5, ou scram)… le dernier étant recommandé. Vous êtes sûr du mot de passe ?

#13 Re : Général » Résolu - Comment limiter le nombre d'exécution d'un trigger? » 25/07/2022 13:41:49

Attention quand même, si ce trigger peut être déclenché par un autre trigger (par exemple parce qu'un autre trigger peut mettre à jour cette table), pg_trigger_depth() ne va pas faire ce que vous espérez. C'est la profondeur totale de triggers, pas le nombre d'appels récursifs de ce trigger seulement.

#14 Re : Général » Résolu - Comment limiter le nombre d'exécution d'un trigger? » 25/07/2022 11:38:46

Une des possibilités est d'utiliser la fonction pg_trigger_depth() (https://www.postgresql.org/docs/14/functions-info.html). Si on peut garantir que ce trigger ne peut pas être déclenché par un autre trigger que par lui-même, ça suffit (ça a toujours été le cas pour moi).

Sinon, si on ne peut pas garantir ça, je pense qu'il faut utiliser https://www.postgresql.org/docs/current … CALL-STACK , et analyser la pile d'appel pour savoir si le trigger a été appelé par lui-même. Mais c'est sale, c'est de l'analyse de chaîne de caractères…

#15 Re : Général » verrou à la lecture » 14/06/2022 09:35:49

Ça veut dire que sur un moteur MVCC, un SELECT ne va pas bloquer un INSERT/UPDATE/DELETE, et l'inverse non plus. Seuls deux ordres de modification de données peuvent entrer en conflit (et les alter table, lock table, etc… évidemment). Les moteurs non-MVCC résolvent le problème avec d'autres méthodes, comme le NOLOCK. C'est un compromis différent.

#16 Re : Général » verrou à la lecture » 20/05/2022 11:05:51

le with nolock de sql server, c'est pour éviter le verouillage des enregistrements lors du select (et surtout pouvoir lire des enregistrements qui sont verrouillés, et donc pourraient être en cours de mise à jour). PostgreSQL fonctionne un peu différemment là-dessus, cf https://www.postgresql.org/docs/current/mvcc-intro.html

#17 Re : Général » suppression doublons » 27/04/2022 15:31:49

OK. C'est mal ! smile

Plus sérieusement, sans PK, on peut accéder les enregistrements par leur CTID…

WITH candidates AS (SELECT ctid, art_id, 
           prix, 
           maj, 
           ROW_NUMBER() OVER(PARTITION BY art_id,
                                          maj
           ORDER BY maj,prix DESC) AS DuplicateCount
    FROM historique_prix WHERE art_id = 6739),
         to_delete AS (SELECT ctid FROM candidates WHERE DuplicateCount > 1)
DELETE FROM historique_prix WHERE ctid IN (SELECT ctid FROM to_delete)

Le problème, c'est qu'un update d'un enregistrement peut changer son CTID (c'est leur adresse physique dans la table). Donc cet ordre SQL pourrait ne pas marcher si il y a des mises à jour concurrentes des enregistrement qu'on veut nettoyer

#18 Re : Général » suppression doublons » 27/04/2022 15:25:30

Bonjour, pas moyen de retrouver les enregistrements comme ça. Il y a une PK à la table ?
Parce que si oui, vous pouvez certainement réécrire ça de la sorte:

WITH candidates AS (SELECT ma_pk, art_id, 
           prix, 
           maj, 
           ROW_NUMBER() OVER(PARTITION BY art_id,
                                          maj
           ORDER BY maj,prix DESC) AS DuplicateCount
    FROM historique_prix WHERE art_id = 6739),
         to_delete AS (SELECT ma_pk FROM candidates WHERE DuplicateCount > 1)
DELETE FROM historique_prix WHERE ma_pk IN (SELECT ma_pk FROM to_delete)

#19 Re : Optimisation » Materialize 25 milliards lignes » 06/04/2022 11:08:40

Les 25 milliards, c'est les "25 milliards d'enregistrements que le nœud a produits", dont la plupart sont ensuite supprimés par le join filter. J'imagine que c'est parce qu'il est obligé de produire ses enregistrements plusieurs fois pour le merge join, si on a n-n id_marque qui correspondent . Pour supprimer le materialize, tu peux essayer de désactiver enable_materialize juste avant d'exécuter cette requête. J'ai déjà eu des environnements où désactiver materialize sur des requêtes apportait de meilleurs résultats... maintenant que j'y repense, la dernière fois, ça devait être une 9.6 smile

#20 Re : Général » PostgreSQL 8.1 » 31/01/2022 10:36:29

Très bonne nouvelle.
J'imagine que vous mettez à jour smile

#21 Re : Général » PostgreSQL 8.1 » 26/01/2022 15:58:18

c'est bizarre, c'est exactement ce que vous deviez faire. On dirait un problème di'nterprétation de la ligne de commande. Essayez de virer le \ juste avant le ", avant le start. Je n'ai aucune idée de comment l'interpréteur de commande de windows va réagir à ça. On dirait que pg_ctl n'a pas vu l'opération start. Comme si pour lui l'option -D l'avait englobé par exemple.

#22 Re : Général » PostgreSQL 8.1 » 25/01/2022 21:03:35

Je pense que vous allez avoir beaucoup de mal à la trouver. La version 8.1 est morte et enterrée depuis longtemps. Ça fait 12 ans qu'elle n'est plus supportée. Si vous ajoutez à ça que les versions windows ont toujours été fournies par une entreprise (EDB), pas par la communauté elle même comme les versions Linux.

Vous avez peut-être plus de chance de réussir à la faire tourner en récupérant aussi le répertoire de postgresql dans le program files de votre machine et en essayant de l'exécuter tel quel (à coup de pg_ctl je pense)

#23 Re : PL/pgSQL » Timestamp et requêtes imbriquées » 19/10/2021 10:27:23

Bonjour,

Comment on considère que plusieurs entrées de carpooling_proofs correspondent au même trajet d'un conducteur ? Parce que là on peut imaginer qu'un conducteur prenne un passager à 14h, un autre à 15h, tous les deux sur le même trajet, et un autre à 17h sur le trajet retour?

#25 Re : .NET » pg_dump avec Postgres 13 et Erreur "trop d'arguments en ligne ..." » 17/03/2021 18:01:58

Bonjour,

Je pense que c'est le ">" qui est en trop. C'est soit "-f nom_de_fichier" (le mieux) , soit "> nom_de_fichier". Le premier est mieux pour les performances à la restauration (je vous épargne les détails)

Pied de page des forums

Propulsé par FluxBB