Je viens de m'apercevoir d'un petit problème avec la libpq sous
Solaris 10 (sparc). PostgreSQL est en version 8.3.5. J'ai un programme
multithreadé qui lance 8 threads, chaque thread faisant un certain
nombre de requêtes séquentiellement. Pour un certain nombre de raisons,
chaque requête ouvre une connexion, effectue une requête et ferme la
connexion.
Problème : j'ai l'affreuse impression que la libpq dans _ce_
contexte crée des processus (un processus par connexion) lors de
_chaque_ écriture (histoire de les faire en tâche de fond). Tous ces
processus finissent bien, mais les connexions durent tant que dure
l'écriture et je me prends des :
FATAL: sorry, too many clients already
Comment contraindre la libpq d'attendre la fin de l'écriture _avant_
de continuer ?
Cordialement,
JKB
--
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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred Brouard - SQLpro
Bonjour,
essayez de passer votre transaction en mode d'isolation SERIALIZABLE.
BEGIN; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; ... COMMIT;
A +
JKB a écrit :
Bonjour à tous,
Je viens de m'apercevoir d'un petit problème avec la libpq sous Solaris 10 (sparc). PostgreSQL est en version 8.3.5. J'ai un programme multithreadé qui lance 8 threads, chaque thread faisant un certain nombre de requêtes séquentiellement. Pour un certain nombre de raisons, chaque requête ouvre une connexion, effectue une requête et ferme la connexion.
Problème : j'ai l'affreuse impression que la libpq dans _ce_ contexte crée des processus (un processus par connexion) lors de _chaque_ écriture (histoire de les faire en tâche de fond). Tous ces processus finissent bien, mais les connexions durent tant que dure l'écriture et je me prends des :
FATAL: sorry, too many clients already
Comment contraindre la libpq d'attendre la fin de l'écriture _avant_ de continuer ?
Cordialement,
JKB
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
Bonjour,
essayez de passer votre transaction en mode d'isolation SERIALIZABLE.
BEGIN;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
...
COMMIT;
A +
JKB a écrit :
Bonjour à tous,
Je viens de m'apercevoir d'un petit problème avec la libpq sous
Solaris 10 (sparc). PostgreSQL est en version 8.3.5. J'ai un programme
multithreadé qui lance 8 threads, chaque thread faisant un certain
nombre de requêtes séquentiellement. Pour un certain nombre de raisons,
chaque requête ouvre une connexion, effectue une requête et ferme la
connexion.
Problème : j'ai l'affreuse impression que la libpq dans _ce_
contexte crée des processus (un processus par connexion) lors de
_chaque_ écriture (histoire de les faire en tâche de fond). Tous ces
processus finissent bien, mais les connexions durent tant que dure
l'écriture et je me prends des :
FATAL: sorry, too many clients already
Comment contraindre la libpq d'attendre la fin de l'écriture _avant_
de continuer ?
Cordialement,
JKB
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
essayez de passer votre transaction en mode d'isolation SERIALIZABLE.
BEGIN; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; ... COMMIT;
A +
JKB a écrit :
Bonjour à tous,
Je viens de m'apercevoir d'un petit problème avec la libpq sous Solaris 10 (sparc). PostgreSQL est en version 8.3.5. J'ai un programme multithreadé qui lance 8 threads, chaque thread faisant un certain nombre de requêtes séquentiellement. Pour un certain nombre de raisons, chaque requête ouvre une connexion, effectue une requête et ferme la connexion.
Problème : j'ai l'affreuse impression que la libpq dans _ce_ contexte crée des processus (un processus par connexion) lors de _chaque_ écriture (histoire de les faire en tâche de fond). Tous ces processus finissent bien, mais les connexions durent tant que dure l'écriture et je me prends des :
FATAL: sorry, too many clients already
Comment contraindre la libpq d'attendre la fin de l'écriture _avant_ de continuer ?
Cordialement,
JKB
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
JKB
Le 19-12-2008, ? propos de Re: Processus, connexions et libpq, Fred Brouard - SQLpro ?crivait dans fr.comp.applications.sgbd :
Bonjour,
essayez de passer votre transaction en mode d'isolation SERIALIZABLE.
BEGIN; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; ... COMMIT;
Je vais essayer. Merci du tuyau,
JKB
-- 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.
Le 19-12-2008, ? propos de
Re: Processus, connexions et libpq,
Fred Brouard - SQLpro ?crivait dans fr.comp.applications.sgbd :
Bonjour,
essayez de passer votre transaction en mode d'isolation SERIALIZABLE.
BEGIN;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
...
COMMIT;
Je vais essayer. Merci du tuyau,
JKB
--
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.
Le 19-12-2008, ? propos de Re: Processus, connexions et libpq, Fred Brouard - SQLpro ?crivait dans fr.comp.applications.sgbd :
Bonjour,
essayez de passer votre transaction en mode d'isolation SERIALIZABLE.
BEGIN; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; ... COMMIT;
Je vais essayer. Merci du tuyau,
JKB
-- 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.
