Vous n'êtes pas identifié(e).
Pages : 1
Merci pour votre réponse. Je m'en vias transformer mes règles en triggers.
Bonne journée.
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.
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);Bonjour Julien,
c'est une machine virtuelle. Tout est ok de ce coté.
Merci encore.
Le redémarrage du serveur a fonctionné. Je peux me connecter à mes bases de données.
Merci Julien.
Très bonne soirée.
Oui j'ai compris après coup... C'est en cours.
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êteIl semble refuser au tout du moins être long à s'arrêter...
ok je teste.
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.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...
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:13832kBMa 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é)
Ca fonctionne,
Merci beaucoup!
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