Bonjour,

vous ne dites pas quelle(s) commande(s) vous utilisez dans votre fichier SQL qui expliquerait la sortie décrite (tout dans la 1ère colonne).

À priori vous devriez pouvoir utiliser la commande COPY ... TO STDOUT WITH ...

Bonsoir,

pour désactiver un trigger il n'y a pas à ma connaissance d'autres possibilités que d'utiliser ALTER TABLE ... DISABLE TRIGGER ...
De plus cette commande prend un verrou (SHARE ROW EXCLUSIVE) de telle manière qu'aucune autre session ne puisse modifier la table de manière concurrente ce qui peut être embêtant si il y a pas mal d'accès simultané.

Les solutions alternatives ? Quelques pistes:

    - Le trigger pourrait être mis sur l'INSERT non ?
    - Un trigger est-il nécessaire ? Pourquoi ne pas faire une requête ad-hoc lorsque vous avez besoin du dernier commentaire ? Problème de performance ? Ajout d'un index sur la table commentaires (CREATE INDEX ON commentaires(id_objet, date_creation)) ?
    - Créer une table spécifique qui ne stocke qu'une référence sur le dernier commentaire de chaque objet (à mettre à jour par exemple via un/des trigger(s) sur la table principale commentaires):

CREATE TABLE last_commentaires(
      id_objet integer
    , id_last_commentaire integer

    , PRIMARY KEY(id_objet, id_last_commentaire)
    , FOREIGN KEY(id_objet) REFERENCES objets(id_objet)
          ON DELETE CASCADE
    , FOREIGN KEY(id_last_commentaire) REFERENCES commentaires(id_commentaire)
          ON DELETE CASCADE
);

Oui la fréquence des checkpoints est plus espacée ce qui fait qu'ils interfèrent moins avec les requêtes. Dans votre cas j'imagine que l'augmentation est telle qu'aucun checkpoint
n'intervient pendant la requête qui peut profiter à 100% de la bande passante ainsi libérée.

L'augmentation de la fréquence des checkpoints n'augmente pas a priori le risque de pertes de données. Par contre il augmente le volume de données que chaque checkpoint aura
à traiter (écrire sur disque). Son impact sera à ce moment là plus important (notamment sur les malheureuses requêtes qui auront la malchance d'être effectuées en même temps).

Et en cas de crash le volume à rejouer des journaux de transaction sera plus important parce que les données qu'ils contiennent n'auront pas été écrites dans les tables de données.

Par contre j'aimerais bien qu'on m'explique en quoi la requête présentée remplie le journal de trasaction au point de déclencher le chekpoint.

Bonjour,

si vous lisez l'anglais vous pouvez aller voir cette page pour vous aider dans vos réglages. Certains réglages varient en fonction de l'OS.

work_mem est fixé à une valeur relativement basse parce que c'est un paramètre qui s'applique à chaque session (même à chaque opération de tri - il peut y en avoir plusieurs simultanément sur une même session).
Vous pouvez probablement l'augmenter avec profit (car il est utilisé pour les tris qui apparaissent dans votre requête) si vous êtes sûr qu'il y aura un nombre restreint d'utilisateurs ou
pouvez baisser ce nombre (max_connections).

Mais c'est le cas automatiquement, c'est le contraire qui demande des instructions particulières (SET ROLE, SET SESSION AUTHORIZATION).

Attendons l'avis des autres participants au forum.

Le \dp tf_test_tes ci-dessus indique que la table se trouve dans le schema proprietaire. Votre vue fait référence à une table qui se trouve dans le schéma symphonie.
Ramenez vous de quelconques données, que ce soit sous user_app ou proprietaire, de cette vue ?

SECURITY DEFINER permet d'indiquer à PostgreSQL qu'il doit exécuter la fonction avec les privilèges du propiétaire de la fonction et pas, comme par défaut, avec les privilèges de l'utilisateur qui exécute la fonction.

Sous une session propriétaire octroyer les droits suivants:

GRANT SELECT ON tf_test_tes, vf_test_tes TO user_app;

puis réessayer les commandes \dp et SELECT sous une session user_app.

Bonjour,

c'est parce qu'à défaut d'indication le client psql se connecte sous le nom d'utilisateur sous lequel vous le lancer (ici root). Et visiblement cet utilisateur n'existe pas pour le serveur PostgreSQL
(PostgreSQL a sa propres liste d'utilisateurs, il n'y a pas obligatoirement correspondance avec la liste des utilisateurs système).

Vous devez vous connecter sous le nom d'un utilisateur au sens PostgreSQL qui a les droits de connexion sur la base de données cible. Avec psql vous indiquez cet utilisateur avec l'option -U.

Vous devriez lire un peu la doc sur le sujet. Un man psql vous aidera également.

Merci pour ces 1ers éléments (je pensais surtout aux 2 requêtes SELECT sur la table étrangère et sur la vue ainsi qu'au(x) erreur(s) éventuelle(s) renvoyée(s) au client).

En l'état je vois que la table étrangère est créée dans le schéma courant et que la vue effectue sa requête sur une table qui est dans le schéma "symphonie". Les 2 schémas sont les mêmes ?

Et la requête dans la vue sélectionne une colonne TYPE que je ne vois pas dans la table.

Si vous pouvez montrer les 2 requêtes qui ne renvoient pas les mêmes résultats et les éventuelles erreurs ca aiderait probablement.

Bonjour,

les fichiers à  importer doivent être accessibles par le serveur (fichiers locaux ou sur un système de fichier "monté" localement au serveur, attention à l'encoding). C'est le cas ?

Aussi je suis étonné par l'argument de quote:

...quote E'\b'...

Le caractère de quotation est backspace ? Il y a quelque chose qui m'échappe...

Bonjour,

quelle est la valeur du paramètre listen_addresses (SHOW listen_addresses) ?

Bonjour,

vous ne pouvez pas faire un simple ALTER TABLE OldName RENAME TO NewName après avoir récupéré la table d'origine tel que ?

Sinon, à l'inverse, il est peut être possible avant de lancer le dump de dupliquer dans BDD1 la table d'origine sous le nouveau nom souhaité:

CREATE TABLE NewName (LIKE OldName INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES);
INSERT INTO NewName SELECT * FROM OldName;

Voir la doc de CREATE et notamment les options possibles de la clause LIKE.

Il y a aussi la solution du COPY TO et COPY FROM.