Vous n'êtes pas identifié(e).
Pages : 1
Re,
J'ai réussi à attraper ma requête en passant mon "log_statement" à "all" pendant un court instant et en rechargeant la configuration.
C'est un peu bourrin et je ne sais pas si ca serait utilisable sur un moteur qui travaille à fond les ballets mais je suis arrivé à mes fins.
Merci à tous !
C'est ballot.
Bon bah, ca ne va pas m'aider pour débugger tout ca !
Merci pour ta réponse.
Bonjour,
J'utilise actuellement une application qui s'appuie sur une base de donnée Postgresql 8.4. Cette application déclare des curseurs et les utilise pour afficher des résultats.
J'ai actuellement un problème de lenteur sur l'utilisation d'un de ces curseurs, et je soupçonne un problème d'index manquant, générant un full table scan.
Pour confirmer ou infirmer mes soupçons, je souhaiterais savoir la requête incluse dans ce curseur et c'est là tout le problème : je ne sais pas comment faire !
J'ai bien trouvé une vue "pg_cursors" mais qui reste désespérément vide.
Mon test actuel :
Je prépare un fichier .sql, dont le contenu est :
SELECT * FROM pg_stat_activity WHERE datname='mydb';
SELECT * FROM pg_cursors;
SELECT * FROM pg_stat_activity WHERE datname='mydb'; J’exécute l'action actuellement lente
J'exécute le script SQL pour voir ce qui se passe
Mon résultat :
datid | datname | procpid | usesysid | usename | current_query | waiting | xact_start | query_start | backend_start | client_addr | client_port
---------+-------------+---------+----------+----------+-------------------------------------------------------------------------------------------+---------+-------------------------------+-------------------------------+-------------------------------+---------------+-------------
7570372 | mydb | 14854 | 16420 | myuser | FETCH 30 FROM CUR162 | f | 2014-01-22 10:57:42.042005+01 | 2014-01-22 10:57:42.042702+01 | 2014-01-22 06:00:37.289572+01 | 192.168.3.109 | 49998
name | statement | is_holdable | is_binary | is_scrollable | creation_time
------+-----------+-------------+-----------+---------------+---------------
(0 rows)
datid | datname | procpid | usesysid | usename | current_query | waiting | xact_start | query_start | backend_start | client_addr | client_port
---------+-------------+---------+----------+----------+-------------------------------------------------------------------------------------------+---------+-------------------------------+-------------------------------+-------------------------------+---------------+-------------
7570372 | mydb | 14854 | 16420 | myuser | FETCH 30 FROM CUR162 | f | 2014-01-22 10:57:42.042005+01 | 2014-01-22 10:57:42.042702+01 | 2014-01-22 06:00:37.289572+01 | 192.168.3.109 | 49998On voit bien le curseur en train d'être parcouru, et pourtant, je n'ai aucune mention dans "pg_cursors".
Ma question est : comment je peux voir les curseurs actuellement déclarés et la requête qu'ils contiennent ?
Merci pour votre aide.
Bonjour,
J'ai une question concernant les droits que possède un utilisateur donné pour se connecter à une base.
Admettons que j'ai un pg_hba.conf assez ouvert, du genre "host all all 192.168.1.0/24 md5". Donc toute personne sur le réseau 192.168.1.0 pourra accéder aux base de mon server postgresql, à condition qu'il fournisse un bon mot de passe.
J'ai deux bases, appelons les "base1" et "base2", qui appartiennent à l'utilisateur "postgres".
Si je créé un utilisateur "test", muni d'un mot de passe, j'ai manifestement le droit de me connecter à toutes les bases, depuis n'importe quel serveur sur 192.168.1.0/24.
Par exemple, un "psql -h <serveur_pg> -d base1 -U test", en entrant le bon mot de passe, la connexion va s'effectuer, je pourrais lister les tables. Je n'ai toutefois pas le droit de faire un select dessus (encore heureux).
Donc soit j'ai raté une subtilité dans la sécurité sur Postgresql, soit la "vraie" barrière se situe au niveau du pg_hba.conf et qu'une fois passé, c'est accès libre pour la connexion sur les bases.
Existe t'il une option / privilège qui empêche explicitement la connexion à tous les utilisateurs, sauf le owner et les utilisateurs clairement spécifiés ?
Merci pour votre aide.
EDIT : je m'auto-réponds : En faisant un "REVOKE CONNECT ON DATABASE base1 FROM PUBLIC", l'utilisateur test n'a plus le droit de se connecter à base1. Par contre, je suis étonné que ca ne soit pas la "norme" que d'interdire tout le monde sauf spécifié explicitement, plutôt que l'inverse. Il existe une option qui permet de faire ca ?
Pages : 1