Vous n'êtes pas identifié(e).

Pages : 1

#1 Re : Général » Clause Returning dans une règle d'insertion sur une vue avec jointures » 27/07/2017 11:23:45

Mathieu BOSSAERT

C'est parfait merci !

http://si.cenlr.org/QGIS_2-18_INSERT_ON_PostGIS_View

#2 Re : Général » Clause Returning dans une règle d'insertion sur une vue avec jointures » 27/07/2017 07:54:03

Mathieu BOSSAERT

Merci pour votre réponse. Je m'en vias transformer mes règles en triggers.

Bonne journée.

#3 Re : Général » Clause Returning dans une règle d'insertion sur une vue avec jointures » 26/07/2017 16:56:49

Mathieu BOSSAERT

J'ai trouvé cette discussion sur le même sujet http://forums.postgresql.fr/viewtopic.php?id=4103

Vous confirmez qu'il vaut mieux que je remplace ma règle ON INSERT par un trigger ?

Merci d'avance.

#4 Général » Clause Returning dans une règle d'insertion sur une vue avec jointures » 26/07/2017 16:31:50

Mathieu BOSSAERT
Réponses : 4

Bonjour à toutes et tous,

je n'ai pas trouvé de sujet correspondant sur le forum et je cale devant l'aide : https://docs.postgresql.fr/9.2/rules-update.html

J'ai créé une vue avec des jointures sur des tables de référence, sur laquelle je fais des INSERT par l'intermédiaire d'une règle. J'ai besoin d'utiliser la clause RETURNING sur ma règle mais je n'arrive pas à la faire fonctionner.
dans cette phrase de la documentation :

vous devrez faire en sorte que les règles incluent les clauses RETURNING qui calcule les lignes de la vue

je ne comprends pas si je dois retourner l'ensemble des champs de la table, l'ensemble des champs de la vue, un mélange des deux...

J'espère que mon explication est claire...

Merci d'avance pour votre attention.

CREATE OR REPLACE VIEW habitats_naturels.saisie_habitats_avec_ref AS 
 SELECT saisie_habitat.id_obs_habitat,
    saisie_habitat.code_site_n2000,
    saisie_habitat.exploitant,
    saisie_habitat.num_parcelle,
    saisie_habitat.remarque,
    saisie_habitat.facies,
    saisie_habitat.hab_1,
    saisie_habitat.rec_hab_1,
    saisie_habitat.hab_2,
    saisie_habitat.rec_hab_2,
    saisie_habitat.hab_3,
    saisie_habitat.rec_hab_3,
    saisie_habitat.hab_4,
    saisie_habitat.rec_hab_4,
    saisie_habitat.hab_5,
    saisie_habitat.rec_hab_5,
    habitat_1.cd_cb AS "1_cd_cb",
    habitat_2.cd_cb AS "2_cd_cb",
    habitat_3.cd_cb AS "3_cd_cb",
    habitat_4.cd_cb AS "4_cd_cb",
    habitat_5.cd_cb AS "5_cd_cb"
   FROM habitats_naturels.saisie_habitat
     LEFT JOIN habitats_naturels.referentiel_habitats habitat_1 ON saisie_habitat.hab_1 = habitat_1.id
     LEFT JOIN habitats_naturels.referentiel_habitats habitat_2 ON saisie_habitat.hab_2 = habitat_2.id
     LEFT JOIN habitats_naturels.referentiel_habitats habitat_3 ON saisie_habitat.hab_3 = habitat_3.id
     LEFT JOIN habitats_naturels.referentiel_habitats habitat_4 ON saisie_habitat.hab_4 = habitat_4.id
     LEFT JOIN habitats_naturels.referentiel_habitats habitat_5 ON saisie_habitat.hab_5 = habitat_5.id;

la règle ON INSERT : 

CREATE OR REPLACE RULE rule_insert AS
    ON INSERT TO habitats_naturels.saisie_habitats_avec_ref DO INSTEAD  INSERT INTO habitats_naturels.saisie_habitat (id_obs_habitat, code_site_n2000, exploitant, num_parcelle, remarque, facies, hab_1, rec_hab_1, hab_2, rec_hab_2, hab_3, rec_hab_3, hab_4, rec_hab_4, hab_5, rec_hab_5)
  VALUES (new.id_obs_habitat, new.code_site_n2000, new.exploitant, new.num_parcelle, new.remarque, new.facies, new.hab_1, new.rec_hab_1, new.hab_2, new.rec_hab_2, new.hab_3, new.rec_hab_3, new.hab_4, new.rec_hab_4, new.hab_5, new.rec_hab_5);

#5 Re : Général » VACCUM FULL : FATAL: le système de bases de données est en cours de re » 20/08/2014 09:54:52

Mathieu BOSSAERT

Bonjour Julien,

c'est une machine virtuelle. Tout est ok de ce coté.

Merci encore.

#6 Re : Général » VACCUM FULL : FATAL: le système de bases de données est en cours de re » 19/08/2014 18:02:02

Mathieu BOSSAERT

Le redémarrage du serveur a fonctionné. Je peux me connecter à mes bases de données.

Merci Julien.

Très bonne soirée.

#7 Re : Général » VACCUM FULL : FATAL: le système de bases de données est en cours de re » 19/08/2014 17:55:36

Mathieu BOSSAERT

Oui j'ai compris après coup... C'est en cours.

#8 Re : Général » VACCUM FULL : FATAL: le système de bases de données est en cours de re » 19/08/2014 17:46:40

Mathieu BOSSAERT

Il a échoué sur l'arrêt (/etc/init.d/postgresql-9.2 restart)
Le démarrage semble ok mais impossible de se connecter : il me répond ceci : 

psql: FATAL:  le système de base de données s'arrête

#9 Re : Général » VACCUM FULL : FATAL: le système de bases de données est en cours de re » 19/08/2014 17:43:24

Mathieu BOSSAERT

Il semble refuser au tout du moins être long à s'arrêter...

#10 Re : Général » VACCUM FULL : FATAL: le système de bases de données est en cours de re » 19/08/2014 17:41:48

Mathieu BOSSAERT

ok je teste.

#11 Re : Général » VACCUM FULL : FATAL: le système de bases de données est en cours de re » 19/08/2014 17:24:24

Mathieu BOSSAERT

rien dans pg_log/ tout était redirigé depuis sur postgres.

Voici ce que je trouve dans pgstartup.log :

 ->  : LOG:  automatic vacuum of table "sicen.pg_catalog.pg_type": could not (re)acquire exclusive lock for truncate scan
 ->  : LOG:  automatic vacuum of table "sicen.pg_catalog.pg_class": could not (re)acquire exclusive lock for truncate scan
 ->  : LOG:  automatic vacuum of table "sicen.pg_catalog.pg_attribute": could not (re)acquire exclusive lock for truncate scan
 ->  : LOG:  automatic vacuum of table "sicen.pg_catalog.pg_type": could not (re)acquire exclusive lock for truncate scan
sicen -> dba : LOG:  envoi de l'annulation pour bloquer le PID 18992 de l'autovacuum
sicen -> dba : DÃTAIL:  Le processus 20949 attend AccessExclusiveLock sur relation 5501835 de la base de données 1389423.
sicen -> dba : INSTRUCTION :  VACUUM FULL VERBOSE dg.parc2
 ->  : ERREUR:  annulation de la tâche d'autovacuum
 ->  : CONTEXTE :  VACUUM automatique de la table « sicen.dg.parc2 »
 ->  : LOG:  processus serveur (PID 20949) a été arrêté par le signal 9 : Killed
 ->  : DÃTAIL:  Le processus qui a échoué exécutait : VACUUM FULL VERBOSE dg.parc2
 ->  : LOG:  arrêt des autres processus serveur actifs
 ->  : ATTENTION:  arrêt de la connexion à cause de l'arrêt brutal d'un autre processus serveur
 ->  : DÃTAIL:  Le postmaster a commandé à ce processus serveur d'annuler la transaction
        courante et de quitter car un autre processus serveur a quitté anormalement
        et qu'il existe probablement de la mémoire partagée corrompue.
 ->  : ASTUCE :  Dans un moment, vous devriez être capable de vous reconnecter à la base de
        données et de relancer votre commande.

#12 Re : Général » VACCUM FULL : FATAL: le système de bases de données est en cours de re » 19/08/2014 17:10:33

Mathieu BOSSAERT

Bonjour Julien,

non, rien de gourmand. la machine est bien dimensionnée et seuls apache et tomcat tournent dessus pour l'intranet très calme en ce moment.

Pas d'autres erreur par la suite si ce n'est le refus de connexion...

#13 Général » VACCUM FULL : FATAL: le système de bases de données est en cours de re » 19/08/2014 16:56:37

Mathieu BOSSAERT
Réponses : 13

Bonjour à tous,

je ne poste pas souvent ici car je n'ai pas de problème avec l'utilisation de postgresql. En tout cas jusqu'à aujourd'hui...

J'ai fait des mises à jour successives sur une table de quelques 4 millions de lignes. La taille de ma table a atteint 19 Go (contre moins de 1Go avant les mises à jour)  et j'ai voulu opérer un VACCUM FULL (je suis le seul à y accéder).

Depuis, mon serveur refuse toute connexion et retourne ce message d'erreur :

"FATAL: le système de bases de données est en cours de restauration "
Le service est en cours d'execution si j'en crois la commande  "service postgresql-9.2 status"

J'avais configuré syslog pour alimenter une base sur le même serveur (ce qui n'est pas très malin après-coup...).

Je viens de le relancer rsyslog pour logger dans les fichiers et voici les dernières lignes de logs concernant postgresql :

Aug 19 16:38:28 postgresql kernel: postmaster invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0, oom_score_adj=0
Aug 19 16:38:28 postgresql kernel: postmaster cpuset=/ mems_allowed=0
Aug 19 16:38:28 postgresql kernel: Pid: 20949, comm: postmaster Not tainted 2.6.32-358.6.2.el6.x86_64 #1
Aug 19 16:38:28 postgresql kernel: [15065]    26 15065   551087     2014   3       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [15068]    26 15068   551944    26488   3       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [15069]    26 15069   551328    20115   2       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [15070]    26 15070   551328       78   0       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [15071]    26 15071   551587      230   3       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [15072]    26 15072    45205      148   1       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [15076]    26 15076   551783      270   0       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [15078]    26 15078   551804      494   1       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [15080]    26 15080   560544     1924   2       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [15081]    26 15081   551603      713   1       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [15300]    26 15300   551636      476   2       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [18255]    26 18255   554906     1751   1       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [18826]    26 18826   552082     1750   0       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [19035]    26 19035   557429    11139   0       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [19515]    26 19515   552384      925   2       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [19642]    26 19642   551798      750   1       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [20919]    26 20919   551636      395   0       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [20949]    26 20949  2807869  1809867   1       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: [20959]    26 20959   551800      775   1       0             0 postmaster
Aug 19 16:38:28 postgresql kernel: Out of memory: Kill process 20949 (postmaster) score 732 or sacrifice child
Aug 19 16:38:28 postgresql kernel: Killed process 20949, UID 26, (postmaster) total-vm:11231476kB, anon-rss:7225636kB, file-rss:13832kB

Ma question est la suivante : mon serveur va-t-il retrouver un état normal ? Dois-je attendre ou le redémarrer ?
En cas de problème plus grave, d'autres objets que la table concernées pourront-ils être impactés ?

Merci beaucoup pour votre attention,

Mathieu (qui a besoin d'être ressuré)

#14 Re : PL/pgSQL » Déclencher un trigger sous une autre identité » 12/08/2010 13:54:09

Mathieu BOSSAERT

Ca fonctionne,

Merci beaucoup!

#15 PL/pgSQL » Déclencher un trigger sous une autre identité » 12/08/2010 13:10:33

Mathieu BOSSAERT
Réponses : 2

Bonjour à tous,

nouveau sur le forum, je suis néanmoins utilisateur de PostgreSQL/PostGIS depuis 4 ans.

Je ne sais pas si la meilleure place de ce post est ici ou dans le forum sécurité ?

Nous développons une interface web de saisie de données qui alimente une table.

A chaque insertion de donnée dans cette table, le tuple créé est ventilé dans la base de données (4 tables). Cela se fait par intermédiaire d'un trigger.

J'aimerai limiter les droit des utilisateurs qui utilisent l'application web aux tables nécessaire à cette application. Or, je suis obligé d'accorder des privilèges à mon utilisateur web sur toutes les tables ventilées car c'est cet utilisateur qui déclenche le trigger.

Ma question est donc la suivante : y a t_il un moyen de déclencher un trigger sous une autre identité que celle qui déclenche le trigger ?

Merci d'avance pour votre attention,

Cordialement,

Pages : 1

Pied de page des forums

Propulsé par FluxBB