Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Merci pour le lien, je l'avais déjà consulté. Mon soucis, c'est que je n'ai pas encore réussi à l'appliquer. Je cherche encore.
Cordialement
Bonjour,
Après plusieurs et réinstalle voici mes remarques :
1-
- réinstallation d'un linux
- installation de Postgres 9.5
- installation de Postgis et PgAgent via StartBuilder => à l'installation demande des paramètres de connexion pour PGAgent
- une fois terminée, PGAgent fonctionne très bien.
2-
- installation d'une version Postgres 9.3 et Postgis
- exécution du fichier pgagent.sql pour créer le catalogue dans cette version de Postgres
- pgagent ne fonctionne pas => normal puisque l'installation d'avant a paramétré les connexions sur la version 9.5
- j'ai voulu modifier le fichier qui donne les connexions (port, base, ...) mais impossible de trouver le bon.
3-
- désinstallation de PGAgent et réinstallation en paramétrant les connexions pour la version 9.3 à l'installe, et cela fonctionne de nouveau
==> conclkusion : il s'agit bien d'un problème des paramètres de connexions. Mais comment les changer sans avoir besoin de désinstaller ou réinstaller PGAgent ?
Cordialement
Bonsoir,
Sur Windows tout fonctionne, en regardant le service, il est bien exécuté avec le compte POSTGRES et le mot de passe adéquate.
Sous linux, avec la même installe et versions, les tâches ne s'exécutent pas.
J'ai regardé à la fois dans les tables du catalogue PGAgent sans rien voir de particulier en dehors du fait qu'il n'y a pas de traces de la tache exécuté.
Le service PGAgent est lancé sur Linux.
Dans le log situé ici /var/log/pgagent.log sous Linux, voici ce qui est noté :
WARNING: Couldn't create the primary connection (attempt 1): FATAL: the database system is starting up
WARNING: Couldn't create the primary connection (attempt 2): fe_sendauth: no password supplied
Je pencherais pour un problème de paramétrage du service PGAgent sous linux qui ne serait pas exécuté avec le bon compte comme sous Windows.
A partir de là, je sèche, je n'ai pas encore trouvé comment paramétrer un service sous Linux.
Cordialement
Bonsoir,
J'ai le même problème d'exécution des jobs de PgAgent sur un serveur Linux avec Postgres 9.3 et Postgis 2.1.
J'ai exécuter le fichier pgagent.sql dans ma base de données, sans problème.
J'ai ensuite planifié un job que j'ai exécuté manuellement après échec d'une tentative de planification. Mais rien ne se passe.
Je suis allé voir dans les logs et rien est écrit.
J'ai vérifié, le service est bien démarré dans Linux.
S'agit-il d'un problème de connexion à la base ?
La même installe sous Windows fonctionne bien.
Merci pour votre aide d'avance.
Bonsoir,
Après test, c'était le rechargement des fichiers de conf qui posait problème. Un simple select pg_reload_conf(); sur le base de données a résolu le pb.
L'installation de la base Postgres-Gis s'est finalisée sous linux et elle tourne.
Merci
Bonjour,
Je viens d'installer en fin de semaine PostGres 9.3, Postgis 2.1 et PGAdmin sur un serveur linux Ubuntu 14.04.
Sur le serveur lui-même (via une console VmWare), le serveur fonctionne, j'accède à ma base de données sous PGAdmin sans problème.
J'ai ensuite configuré les fichiers de configuration postgressl.conf et pg_hab.conf pour que le serveur puisse être écouté par les PC ou les autres serveurs de mon réseau.
Pour que le serveur prenne en compte ces modifications j'ai relancé le serveur (ou je crois l'avoir fait par les commandes linux recommandées sur des sites), sans succès en testant de me connecter via PGAdmin sur mon PC. AU début c'était un pb de port qui n'était pas ouvert (résolu) et le message suivant m'indique bien que mon ip n'est pas pris en compte dans le fichier pg_hba.conf (cf ci-dessous).
La commande pg_ctl n'a pas marché car linux ne veut pas m'installer le paquet correspondant pour des pbs de dépendances. La relance de la machine Linux n'a pas résolu le pb.
En cherchant, j'ai pu voir qu'on pouvait faire directement le rechargement des configurations en sql avec cette requête (SELECT pg_reload_conf();).
Comme je n'ai pas pu la tester (je le ferais lundi matin). Je voulais savoir si le fait de relancer le serveur virtuelle hébergeant linux relance également le serveur postgres en rechargeant les fichiers de configuration ?
Merci pour votre aide.
-------------------------------------------------------------------------------------------
Accès refusé à la base de données
Le serveur n'a pas autorisé l'accès à la base de données : le serveur rapporte
FATAL: no pg_hba.conf entry for host "192.168.10.182", user "postgres", database "postgres", SSL off
Pour accéder à la base de données sur un serveur PostgreSQL, vous devez tout d'abord autoriser l'accès au serveur pour votre client (authentification basée sur l'hôte). PostgreSQL vérifiera le fichier pg_hba.conf si un modèle correspondant à votre adresse, nom d'utilisateur, base de données est présent et activé avant même que les listes de contrôle d'accès SQL ne soient évaluées.
La configuration initiale de pg_hba.conf est assez restrictive pour éviter des failles de sécurité involontaires causées par une configuration non acceptée. Vous souhaiterez probablement quelque chose comme
host all all 192.168.0.0/24 md5
Cet exemple autorise les accès à toutes les bases de données de tous les utilisateurs sur le réseau privé 192.168.0.0/24 à condition que l'identification se fasse via des mots de passe cryptés en MD5.
Vous pouvez utiliser l'éditeur du fichier pg_hba.conf intégré à pgAdmin III pour modifier le fichier de configuration pg_hba.conf. Après l'avoir modifié, vous aurez besoin de demander le rechargement de la configuration du serveur en utilisant pg_ctl ou en arrêtant puis en redémarrant le processus serveur.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
RE-
Je viens de trouver apparemment
Pour info et suite
SELECT
*
FROM
information_schema.routines
WHERE
routine_name LIKE '<name function>'
Bonjour,
Je recherche une requête simple pour recherche les tables faisant appel à un trigger x.
Cordialement
Bonsoir,
OK merci, je suis en cours de développement en ce moment, et j'ai opté pour le maximum de trigger pour tout ce qui est modification de données liées à la géométrie.
Je suis resté sur le système de règles pour la simple modification d'attributs liés à une vue contenant ma géométrie. J'ai développé des triggers pour la modification attributaire des tables de niveaux supérieurs suites à la modif de la table appelée par cette vue.
J'ai également introduit pour la clé primaire idgeo une séquence commune.
Depuis cela semble bien fonctionné.
Je note votre remarque sur les règles qui me rassure quand à mes soucis antérieurs.
Merci
Re-
J'apporte des éléments de réponses.
En passant par un idgeo avec une séquence, le pb a priori disparaît.
Mais j'avais également une vue appelant 3 tables, et là les modifications posaient également pb avec ma règle. En ne gardant que 2 tables, le pb disparait.
Bizarre quand même. Je suis preneur de toutes informations pouvant m'aider à mieux comprendre.
Merci
Bonjour,
Depuis 1 semaine, j'ai des problèmes de modifications de données via une vue et la définition de règles.
J'ai 2 tables, une contenant la géométrie et l'autre les attributs. Chacune possède un identifiant idgeo en integer.
J'ai une vue qui permet de rassembler les valeurs des 2 tables
CREATE OR REPLACE VIEW m_amenagement.geo_v_site_ope AS
SELECT row_number() OVER () AS gid, o.idgeo, so.l_nom, so.dest, so.date_crea,
so.z_proced, o.ref_spa, so.date_sai AS date_sai_att,
so.date_maj AS date_maj_att, o.date_sai AS date_sai_obj,
o.date_maj AS date_maj_obj, so.op_sai AS op_sai_att, o.op_sai AS op_sai_obj,
o.surf_brt, o.geom
FROM m_amenagement.an_amt_site_ope so, r_objet.geo_objet_peri_ope o
WHERE so.idgeo = o.idgeo;Sur cette vue, j'y intègre une règle de modification
CREATE OR REPLACE RULE metier_modif_site_ope AS
ON UPDATE TO m_amenagement.geo_v_site_ope
DO INSTEAD UPDATE m_amenagement.an_amt_site_ope SET
idgeo = new.idgeo,
l_nom= new.l_nom,
dest = new.dest,
date_crea = new.date_crea,
date_maj = now(),
op_sai = new.op_sai_obj
WHERE an_amt_site_ope.idgeo = new.idgeo;Pour faire mes insertions et modifications, j'utilise QGIS 2.4 sur une base Postgres 9.0.
Après saisie, j'obtiens 3 valeurs dans me table attributaire
idgeo date_crea
100 2012
200 2015
300 2016
Si je modifie dans QGIS via ma vue la date 2015 pour idgeo=100, il l'enregistre dans l'idgeo = 300.
Quelles solutions ou quels problèmes peuvent être la cause de ce phénomène ?
Faut-il obligatoire que l'identifiant unique idgeo soit une séquence ?
Merci pour vos réponses, je galère.
Cordialement
Pages : 1