accès aux groupes de discussion, consultation et publication d'articles, recherche de "newsgroups"...
membres, identifiez-vous
é-mail Mot de passe
nouveau ? mot de passe oublié ?
Chargement... Chargement en cours...

Groupes français belges canadiens suisses internationaux Nétiquette
Échangez opinions et commentaires dans les forums de discussion.

PostgreSQL 8.2, NetBSD 4.0 et 'too many open pipes'

 [  Nouvelle Discussion Nouvelle discussion  |  Répondre au groupe Répondre au groupe  |  fr.comp.os.bsd ] 

Retour : Accueil du site fr comp os bsd   charte stats de ce groupe


  Sujet:   PostgreSQL 8.2, NetBSD 4.0 et 'too many open pipes'  
 De: knatsc...@koenigsberg.fr (JKB)
 Groupes: fr.comp.applications.sgbd, fr.comp.os.bsd
 Suivi-à: fr.comp.os.bsd
 Organisation: Nerim -- xDSL Internet Provider
 Date: 24. Apr 2008, 08:05:11
Bonjour à tous,

	Je reviens vers vous en raison d'un problème bizarre. J'utilise une
	base de test sur une antique SS20 bipro (cartographie) sur laquelle
	tourne un NetBSD 4.0 des familles. Une grosse application
	d'optimisation tourne sur une machine distante et effectue des
	requêtes sur cette brave SS20 à l'aide de la bibliothèque PQ. Cela
	fonctionne (enfin fonctionne presque). Je m'entends, les requêtes
	passent sans problème, mais ce matin après deux jours de calcul, mon
	programme d'optimisation était dans l'état S (tous les threads).
	Je pensais donc avoir écrit un truc foireux dans mon code. Sauf
	qu'en essayant d'accéder à ma SS20, je me suis pris dans la figure
	un "too many open pipes". Visiblement, NetBSD est resté coincé dans
	une requête SQL, mais je ne vois pas trop pourquoi.

	Requête :

select s.x1, s.y1, s.x2, s.y2, s.gid, s.length, s.time, s.source,
s.target from streets_base_edges as s, (select edge_id, step from
shortest_path('select gid::int4 as id, source::int4, target::int4,
time::float8 as cost, reverse_time::float8 as reverse_cost from
streets_base_edges', 75232, 54194, false, true)) as a where
a.edge_id=s.gid order by a.step

	Si je lance cette requête à la main, ça fonctionne parfaitement.
	Je subodore un problème du côté de NetBSD, mais je ne vois pas trop
	lequel. À tout hasard, ma séquence d'instruction côté client est :

	PQsetdbLogin()
	PQstatus()
	PQexec()
	PQresultStatus()
	PQnfields()
	PQntuples()
	PQgetisnull()
	PQgetlength()
	PQgetvalue()
	PQclear()
	PQfinish()

	Je ne vois pas trop où un pipe pourrait rester ouvert de ce côté.
	Je suis en train de compiler un lsof pour voir ce qui se passe de
	façon plus fine côté NetBSD, mais j'ai un peu peur... Cette machine
	ne fait que répondre à ces requêtes. Elle ne fait strictement rien
	d'autre.

	Est-ce un problème connu ou ai-je raté quelque chose dans
	l'utilisation de la libpq ? Je n'ai pas l'impression que le problème
	se pose lorsque le serveur postgres tourne sous Linux.

	Cordialement,

	JKB

PS: XPost+FU2

-- 
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.


DateSujet  Auteur
01.01.
o 
Groups Explorer contact votre avis comment ça marche? rechercher un groupe suggérer un groupe abuse accueil du site   Imprimer cette page   Envoyer cette page à un(e) ami(e)