Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
L'installation (modulo quelques details) s'est bien passée et la version 8.3.8 se lance bien sur notre serveur.
Par contre il reste le problème de PHP/apache. Celui-ci semble ne pas pouvoir se connecter DE TEMPS EN TEMPS.
Le code suivant :
<?php
ini_set('track_errors','on');
$conn = @pg_connect("host=localhost dbname=toto user=dico password=toto");
echo "Connection result: ";
print_r($conn);
echo "<hr>";
if ($conn===false) {
echo "Connection failed: ";
print_r($php_errormsg);
echo "<hr>";
}
?>
renvoie en général cela
Connection result: Resource id #2
mais de temps en temps ceci :
Connection failed: pg_connect() [function.pg-connect]: Unable to connect to PostgreSQL server: could not connect to server: Is the server running on host "localhost" and accepting TCP/IP connections on port 5432
Avez-vous déjà eu des retours sur ce problème ?
Quels sont vos suggestions/idées ?
merci pour votre aide...je suis sec !
hfilliere
Hors ligne
- Quel système d'exploitation ?
- Avez vous quelquechose dans les logs postgresql ?
Marc.
Hors ligne
Bonjour,
>> Quel système d'exploitation ?
HP-UX-itanium IA64 B.11.23.06
>> Avez vous quelquechose dans les logs postgresql ?
Afin de répondre à cette question, je vais vous transmettre la séquence de tests et investigation que nous avons initié:
--------------------------------------------
Suite à une erreur voici les messages dans le log:
127.0.0.1(52808) @ 2010-02-12 09:59:37.525 MET @ 2010-02-12 09:59:37 MET @@LOG: 08P01: incomplete startup packet
127.0.0.1(52808) @ 2010-02-12 09:59:37.525 MET @ 2010-02-12 09:59:37 MET @@LOCATION: ProcessStartupPacket, postmaster.c:1405
Nouvelle tentative échouant:
@ 2010-02-12 09:59:48.048 MET @ 2010-02-12 09:59:48 MET @@LOG: 00000: connection received: host=127.0.0.1 port=52810
@ 2010-02-12 09:59:48.048 MET @ 2010-02-12 09:59:48 MET @@LOCATION: BackendInitialize, postmaster.c:3036
127.0.0.1(52810) @ 2010-02-12 09:59:48.048 MET @ 2010-02-12 09:59:48 MET @@LOG: 08P01: incomplete startup packet
127.0.0.1(52810) @ 2010-02-12 09:59:48.048 MET @ 2010-02-12 09:59:48 MET @@LOCATION: ProcessStartupPacket, postmaster.c:1405
en alternance avec le message précédent:
@ 2010-02-12 17:33:20.845 MET @ @@LOG: 00000: getsockname() failed: Invalid argument
@ 2010-02-12 17:33:20.845 MET @ @@LOCATION: StreamConnection, pqcomm.c:612
Process autovaccum démarrant automatiquement (normal):
@ 2010-02-12 09:59:53.203 MET @ 2010-02-12 09:59:53 MET @@DEBUG: 00000: autovacuum: processing database "postgres"
@ 2010-02-12 09:59:53.203 MET @ 2010-02-12 09:59:53 MET @@LOCATION: AutoVacWorkerMain, autovacuum.c:1616
Ca remarche:
@ 2010-02-12 10:02:21.228 MET @ 2010-02-12 10:02:21 MET @@LOG: 00000: connection received: host=127.0.0.1 port=52828
@ 2010-02-12 10:02:21.228 MET @ 2010-02-12 10:02:21 MET @@LOCATION: BackendInitialize, postmaster.c:3036
127.0.0.1(52828) @ 2010-02-12 10:02:21.228 MET @ 2010-02-12 10:02:21 MET @@LOG: 00000: connection authorized: user=postgres database=mabase
127.0.0.1(52828) @ 2010-02-12 10:02:21.228 MET @ 2010-02-12 10:02:21 MET @@LOCATION: BackendInitialize, postmaster.c:3107
127.0.0.1(52828) @ 2010-02-12 10:02:21.231 MET @ 2010-02-12 10:02:21 MET @@LOG: 00000: disconnection: session time: 0:00:00.003 user=postgres database=mabase host=127.0.0.1 port=52828
127.0.0.1(52828) @ 2010-02-12 10:02:21.231 MET @ 2010-02-12 10:02:21 MET @@LOCATION: log_disconnections, postgres.c:4037
Ce qu'on trouve sur le net par rapport au message 08P01:
Broken client software, or possibly something portscanning your machine. It's reporting a bogus connection attempt.
Dans le source postmaster.c on retrouve les tests générant l'erreur que l'on trouve dans les log:
Lignes 1321 et suivantes:
if (pq_getbytes((char *) &len, 4) == EOF)
{
/*
* EOF after SSLdone probably means the client didn't like our
* response to NEGOTIATE_SSL_CODE. That's not an error condition, so
* don't clutter the log with a complaint.
*/
if (!SSLdone)
ereport(COMMERROR,
(errcode(ERRCODE_PROTOCOL_VIOLATION),
errmsg("incomplete startup packet")));
return STATUS_ERROR;
}
Lignes 1347 et suivantes:
/*
* Allocate at least the size of an old-style startup packet, plus one
* extra byte, and make sure all are zeroes. This ensures we will have
* null termination of all strings, in both fixed- and variable-length
* packet layouts.
*/
if (len <= (int32) sizeof(StartupPacket))
buf = palloc0(sizeof(StartupPacket) + 1);
else
buf = palloc0(len + 1);
if (pq_getbytes(buf, len) == EOF)
{
ereport(COMMERROR,
(errcode(ERRCODE_PROTOCOL_VIOLATION),
errmsg("incomplete startup packet")));
return STATUS_ERROR;
}
Dans le source pqcomm.c on retrouve l'erreur de socket:
00607 /* fill in the server (local) address */
00608 port->laddr.salen = sizeof(port->laddr.addr);
00609 if (getsockname(port->sock,
00610 (struct sockaddr *) & port->laddr.addr,
00611 &port->laddr.salen) < 0)
00612 {
00613 elog(LOG, "getsockname() failed: %m");
00614 return STATUS_ERROR;
00615 }
Rajout dans le script test_bug.php de la fermeture de la connexion à la base en fin de script:
pg_close($conn);
Cela ne change rien dans les logs.
Suppression des données de la table:
sous user postgres:
psql mabase
mabase=# truncate table matable ;
mabase=# select * from matable ;
id | val1 | val2 | val3
----+------+------+------
(0 rows)
\q pour sortir de psql
On créé le script /opt/hpws/apache/htdocs/insert.php pour alimenter la base avec des enregistrements générés au hasard.
Le script rajoute un enregistrement et affiche le contenu de toute la table après cet insertion.
La consultation se fait avec le script consult.php, et le script test_bug.php ne fait que des connections à la base.
id | val1 | val2 | val3
------+-----------+-----------+------
6904 | RACHID | BENJAMIN | 21
6695 | ANTHONY | GUILLAUME | 62
138 | JULIEN | JEREMY | 42
ETC...
On refait les tests en surveillant les trames réseau:
tcpdump -vv tcp port 5432 and host 'localhost'
tcpdump -vv host not 'localhost'
Rien de très parlant
Modification des paramètres de postgres dans postgres.conf:
authentication_timeout = 5min (valeur précédente: 1min)
puis test avec la valeur 1s
Arrêt / Relance de postgres SOUS USER POSTGRES:
/opt/iexpress/postgresql/bin/pg_ctl stop -D /var/tmp/data -s -m fast > logfile 2>&1
/opt/iexpress/postgresql/bin/postmaster -D /var/tmp/data/ > logfile 2>&1 &
Problème identique
Réinitialisation du paramètre précédent à sa valeur d'origine et test d'autres paramètres selon le même principe:
tcp_keepalives_idle = 5 (valeur précédente: 0)
tcp_keepalives_interval = 5 (valeur précédente: 0)
tcp_keepalives_count = 10 (valeur précédente: 0)
Problème identique
archive_mode = on (valeur précédente: off)
Problème identique
autovacuum = off (valeur précédente: on)
Vérification des pramètres kernel qui ont l'air suffisants par rapport à ce qui est préconisé dans la documentation postgres:
shmmax: 1073741824
shmseg: 300
shmmni: 400
semmni: 2048
semmns: 4096
semmsl: 2048
semvmx: 32767
La vérification du fichier pg_hba.conf ne donne rien non plus:
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
>>>> #host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
On essaie de commenter la 1° ligne de type host, pour forcer les connexions à passer par les sockets Unix plutôt que par TCP/IP. Arrêt relance de postgres.
Au début semble permettre le bon fonctionnement de test_bug.php, mais au bout d'un moment les erreurs reviennent.
Retour arrière au niveau de pg_hba.conf .
Test de différentes syntaxe:
avec ou sans indiquer le host dans la variable de connexion
utilisation d'une connexion persistante avec le mot clé pconnect au lieu de connect
test de diverses fonctions php pour avoir plus d'informations mais sans succès (notamment utilisation de la fonction pg_trace pour tracer les échanges entre PHP et postgres)
Phénomènes curieux:
le fait de rajouter dans le script consult.php, la commande php qui suit, cela provoque l'apparition du problème qui ne se manifeste pas habituellement avec cette page.
Par contre dans le script test_bug.php, cela ne change rien à la présence ou pas de l'erreur.
La commande php concernée est ini_set('track_errors','on').
Elle force, le temps du script, la valeur du paramètre track_errors à vrai, ce qui permet de récupérer dans la variable $php_errormsg le dernier message d'erreur de php. Mais ici rien ne s'affiche au moment de l'erreur (pas d'erreur côté php?) .
Autres cas:
Dans le script consult.php:
Si on veut rajouter la fonction permettant de compter le nombre d'enregistrement résultant d'une commande select ($nb_enr = pg_num_rows($result);) , on a une erreur identique à celle qu'on rencontrait jusque là, dans les log postgres et dans la page web, avec en plus le message "Exec format error " dans la page web.
Idem si on affiche une variable qui n'existe pas
Si on reexécute la fonction pgquery avec la même variable de retour que précédemment: ça marche
Si on change le nom de la variable de retour, on a la même erreur que ci-dessus.
Mais si on affiche par echo le contenu de cette nouvelle variable, on a l'erreur d'origine mais sans celle "Exec format error ".
Dès qu'on commente toutes ces lignes supplémentaires, tout remarche.
Il semble donc y avoir un lien très fort entre le source PHP et l'erreur figurant dans le log de postgres.
Le script consult.php passe dans 99% des cas, par contre le script test_bug.php bloque la plupart du temps. Je vide le contenu du script test_bug.php et je le remplace par celui du script consult.php: le script fonctionne. Il y a donc quelque chose qui ne va pas dans la syntaxe du script d'origine test_bug.php. En le simplifiant (une fonction pg_connect et une fonction pg_close) le script fonctionne plus souvent qu'avant, mais pas tout le temps.
Examen des log php:
/opt/hpws/apache/logs/php.log
Rien de plus
Paramétrage du fichier /opt/hpws/apache/conf/php.ini:
Test de l'activation du buffer de sortie, pour voir:
; Output buffering allows you to send header lines (including cookies) even ; after you send body content, at the price of slowing PHP's output layer a ; bit. You can enable output buffering during runtime by calling the output ; buffering functions. You can also enable output buffering for all files by ; setting this directive to On. If you wish to limit the size of the buffer ; to a certain size - you can use a maximum number of bytes instead of 'On', as ; a value for this directive (e.g., output_buffering=4096).
;output_buffering = Off
output_buffering = On
Rédémarrage du serveur Apache:
/opt/hpws/apache/bin/apachectl stop puis start
Pas d'effet : retour arrière
; Implicit flush tells PHP to tell the output layer to flush itself
; automatically after every output block. This is equivalent to calling the
; PHP function flush() after each and every call to print() or echo() and each
; and every HTML block. Turning this option on has serious performance
; implications and is generally recommended for debugging purposes only.
;implicit_flush = Off
implicit_flush = On
Idem
max_execution_time = 30 Passé de 30 à 90 ; Maximum execution time of each script, in seconds
max_input_time = 60 Passé de 60 à 120 ; Maximum amount of time each script may spend parsing request data
error_reporting = E_ALL & ~E_NOTICE
changé par error_reporting = E_STRICT & E_ALL
display_startup_errors = Off changé par
display_startup_errors = On
pgsql.auto_reset_persistent = Off changé par
pgsql.auto_reset_persistent = On
[Sockets]
; Use the system read() function instead of the php_read() wrapper.
sockets.use_system_read = On mis à Off
Vérification de la configuration de Bastille:
Fichier de configuration : /etc/opt/sec_mgmt/bastille/config
Sauvegarde du fichier avant modification :
cp -p /etc/opt/sec_mgmt/bastille/config /etc/opt/sec_mgmt/bastille/config.sv
Autres fichiers:
/var/opt/sec_mgmt/bastille/log/action-log
/var/opt/sec_mgmt/bastille/log/error-log
Quel est l'effet de cette ligne ?:
# Q: Would you like to deactivate the HP Web Services Apache Web Server?
Apache.deactivate_hpws_apache="Y"
On la met à "N" pour voir l'effet, au travers de l'assistant graphique. On applique les modifications par la commande: bastille -b -f /etc/opt/sec_mgmt/bastille/config
Aucun effet sur le bug – retour arrière
Relance d'Apache, car visiblement Bastille l'a arrêté.
Ipfilter est lancé, mais par défaut il laisse tout passer:
root@3sora01 : ipf -V
ipf: HP IP Filter: v3.5alpha5 (A.11.23.15.01) (376)
Kernel: HP IP Filter: v3.5alpha5 (A.11.23.15.01)
Running: yes
Log Flags: 0 = none set
Default: pass all, Logging: available
Active list: 1
Rien de tout cela ne semble jouer. Le script consult.php semble toujours fonctionner, alors que test_bug.php plante régulièrement. Si on remplace le source par celui de consult.php le script se met à fonctionner. Donc mystère, sachant que les différences entre les 2 scripts sont minimes.
Pour savoir si le problème est lié à la version de php, on tente d'installer une version plus récente trouvée sur le site de produits libres HP (http://hpux.connect.org.uk/ ):
php 5.2.11
Arrêt d'Apache: /opt/hpws/apache/bin/apachectl stop
Sauvegarde du fichier php.ini au cas où:
cp -p /opt/hpws/apache/conf/php.ini /opt/hpws/apache/conf/php.ini.5.2.2
swinstall -s /var/tmp/0_depots/php-5.2.11-ia64-11.23.depot \*
La librairie php correspondant à cette version de php est située là:
/usr/local/apache2/lib/modules/libphp5.so
On modifie donc la configuration d'Apache en conséquence:
Sauvegarde de la configuration précédente d'Apache:
cp -p /opt/hpws/apache/conf/httpd.conf /opt/hpws/apache/conf/httpd.conf.5.2.2
Edition de /opt/hpws/apache/conf/httpd.conf pour remplacer la ligne
LoadModule php5_module modules/libphp5.so
par
LoadModule php5_module /usr/local/apache2/lib/modules/libphp5.so
Problème avec le module php de la nouvelle version (visiblement un problème de compilation du module) :
Redémarrage d'Apache et exécution du script test.php affichant les infos sur PHP:root@3sora01 : /opt/hpws/apache/bin/apachectl start
Syntax error on line 232 of /opt/hpws/apache/conf/httpd.conf:
Cannot load /usr/local/apache2/lib/modules/libphp5.so into server: '/usr/local/apache2/lib/modules/libphp5.so' is not a valid load module: Bad magic number
On désinstalle alors cette version (+ suppression de l'arborescence vide+ retour arrière de la config Apache) et on installe une nouvelle version de serveur Web Apache récupéré sur le site HP:
swlist -s /var/tmp/0_depots/Apache_Based_Web_Server_-V.3.02-HPUXWS22ATW-B302-64.depot
# Bundle(s):
hpuxws22Apache B.2.2.8.01.02 HP-UX Apache-based Web Server
hpuxws22Tomcat B.5.5.27.01.01 HP-UX Tomcat-based Servlet Engine
hpuxws22Webmin A.1.070.10 HP-UX Webmin-based Admin
Au lieu de ce qui est livré avec le socle 2.4:
hpuxwsAPACHE B.2.0.59.01 HP-UX Apache-based Web Server
hpuxwsTOMCAT B.5.5.23.00 HP-UX Tomcat-based Servlet Engine
hpuxwsWEBMIN A.1.070.10 HP-UX Webmin-based Admin
Installation du bundle complet:
swinstall -s /var/tmp/0_depots/Apache_Based_Web_Server_-V.3.02-HPUXWS22ATW-B302-64.depot \*
Nécessite 2 dépendances:
openssl.OPENSSL-LIB,r>=A.00.09.07m.021
krb5client.KRB5-64SLIB-A,r>=D.1.6.2
Comme on n'a pas l'intention d'utiliser ces fonctionnalités, on passe outre ces prérequis.
swinstall -x enforce_dependencies=false -x autoselect_dependencies=false -s /var/tmp/0_depots/Apache_Based_Web_Server_-V.3.02-HPUXWS22ATW-B302-64.depot \*
root@3sora01 : swlist -l product | grep -i hpuxw
hpuxws22APACHE B.2.2.8.01.02 HP-UX Apache-based Web Server
hpuxws22TOMCAT B.5.5.27.01.01 HP-UX Tomcat-based Servlet Engine
hpuxws22WEBMIN A.1.070.10 HP-UX Webmin-based Admin
hpuxwsAPACHE B.2.0.59.01 HP-UX Apache-based Web Server
hpuxwsTOMCAT B.5.5.23.00 HP-UX Tomcat-based Servlet Engine
hpuxwsWEBMIN A.1.070.10 HP-UX Webmin-based Admin
Visiblement les 2 produits coexistent. Pour la version qui nous intéresse les fichiers sont installés dans: /opt/hpws22/apache (au lieu de /opt/hpws/apache/)
et pour php: /opt/hpws22/apache/modules/libphp5.so
Edition du fichier de configuration Apache (après sauvegarde avec l'extension .ori)
/opt/hpws22/apache/conf/httpd.conf
Répertoire par défaut du serveur: /opt/hpws22/apache/htdocs
on recopie les scripts php dans ce répertoire
On décommente la ligne concernant php:
LoadModule php5_module modules/libphp5.so
Les logs sont correctement configurées par défaut.
Configuration de /opt/hpws22/apache/conf/php.ini :
on décommente la ligne correspondant à Postgres extension=pgsql.sl
Lancement du serveur Apache et tests:
/opt/hpws22/apache/bin/apachectl start
Nous avons de nouveau l'erreur avec le script test_bug.php
Version utilisées (d'après phpinfo) :
Apache/2.2.8 HP-UX_Apache-based_Web_Server (Unix) DAV/2 PHP/5.2.6
PostgreSQL(libpq) Version 8.2.5
Contre la version du socle 2.4:
Apache/2.0.59 HP-UX_Apache-based_Web_Server (Unix) DAV/2 PHP/5.2.2
PostgreSQL(libpq) Version 8.1.5
Le serveur postgres est toujours dans la version: 8.3.8
On teste pour voir si les autres postgres, utilisés par des process liés à cimserver, ne pertubent pas le fonctionnement de notre postgres 8.3.8
Arrêt des autres postgres tournant sur le serveur:
/sbin/init.d/sfmdb stop
/sbin/init.d/hpsmdb stop
Réinitialisation de notre postgres/Apache, pour repartir propre:
Arrêt du postgres 8.3.8, arrêt/relance d' Apache, relance du postgres 8.3.8
Le bug se reproduit. Relance de sfmdb et hpsmdb.
Scripts de test:
http://XX.XX.XX.XX/test_bug.php
http://XX.XX.XX.XX/consult.php
Ce qui ressort de tous ces tests:
le bug n'est pas lié à la version de php
c'est le script test_bug.php qui a l'air de planté , l'autre script de test consult.php ne plante pas (ou alors très rarement). Le simple fait de rajouter les lignes supplémentaires, figurant dans consult.php, dans test_bug.php, le script ne plante plus. C'est assez curieux, mais c'est pourtant ce qu'on constate. Peut-être une piste ?
Source du script plantant régulièrement test_bug.php:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
<head>
<title>TEST BASE POSTGRESQL</title>
</head>
<body>
<?php
echo "TEST DE CONNEXION<BR>" ;
$dbh = pg_connect("dbname=mabase user=postgres password=postgres");
echo "<BR>RESULTAT DE LA CONNEXION: ";
print_r($dbh);
echo "<br>";
$sql = "SELECT * FROM matable";
$result = pg_query($dbh, $sql);
//Lignes figurant en plus dans consult.php et qui semblent arrêter le plantage du script test_bug?php quand on les réactive:
//echo "<PRE>";
//while ($row = pg_fetch_array($result)) {
// echo "<BR>Id: " . $row[0] . " Prenom: " . $row[1] . " Nom: " . $row[2] . " Age: " . $row[3] . "<BR>" ;
// }
//echo "</PRE>";
pg_close($dbh);
?>
</body>
</html>
---------------------------------
- Qu' en dites vous ? Est-ce que ca vous parle ce problème?
Merci pour votre aide.
hfilliere
Dernière modification par hfilliere (26/02/2010 11:05:58)
Hors ligne
Avez vous déjà essayé votre script en lui faisant attaquer une autre base de données (au hasard, sur un serveur sous Linux ou éventuellement Windows) ?
Comme vous vous en doutez, HP UX sur Itanium 2 n'est pas la cible la plus courante et la plus testée avec PostgreSQL. Cela permettrait de circonscrire les recherches.
Marc.
Hors ligne
Remarque sans doute idiote, mais avec un pg_pconnect (connexion persistante) à la place de pg_connect, ça n'aiderait pas ?
Autre piste (différente au niveau de l'architecture, mais semblable au niveau de la réflexion): utiliser un pooler de connexion (pg_bouncer ou pg_pool II) ?
Je gère des sites qui voient des millions de page chaque jour. Sans les connexions persistantes, chaque script crée une nouvelle connexion à la base, ce qui a pour effet d'écrouler le serveur PostgreSQL. En évacuant ce problème, il se tourne les pouces. Et pourtant, il en exécute, des requêtes !
Hors ligne
Si le système a des problèmes pour effectuer des connexions, pconnect rendra juste le problème moins fréquent, et donc plus dur à débugguer. Une fois le problème résolu, par contre, c'est effectivement un axe d'amélioration des performances.
Marc.
Hors ligne
Merci à tous pour vos réponses.
Nos actions:
- Tests de pg_pconnect: Toujours le même souci mais moins fréquent.
- Tests sur une autre plateforme: en cours
- Concernant pgbouncer/pgpool II. Nous n'avons qu'une seule connexion. l'outil mis en oeuvre n'est pas ouvert à l'extérieur, il sert de base pour la création de fichiers sources.
Nous vous informons asap des tests sur un autre type de plateforme.
Si toutefois, le souci n'est présent que sur HP-UX, nous concentrerons nos recherches côté sockets.
Merci pour votre aide.
cord.
Hfilliere
Hors ligne
On essaie de commenter la 1° ligne de type host, pour forcer les connexions à passer par les sockets Unix plutôt que par TCP/IP. Arrêt relance de postgres.
Au début semble permettre le bon fonctionnement de test_bug.php, mais au bout d'un moment les erreurs reviennent.
Il n'est pas possible de forcer les sockets unix de cette manière (en changeant uniquement le pg_hba.conf), c'est le client qui doit choisir s'il se connecte en socket unix ou TCP/IP.
Par ailleurs le message d'erreur indiqué côté client ne peut pas se produire avec une connexion par socket unix.
Pour se connecter en socket unix, mettre dans le champ host le chemin complet de la socket, commençant par un slash, par exemple host=/var/run/postgresql/.s.PGSQL.5432
Si nécessaire, regarder dans postgresql.conf pour avoir l'emplacement du fichier, ou netstat -l qui doit aussi l'indiquer
Dernière remarque, le post parle beaucoup de comparaison entre deux scripts, mais ces deux scripts n'utilisent pas la même méthode de connexion, il y en a qui fait:
$conn = @pg_connect("host=localhost dbname=toto user=dico password=toto");et l'autre
$dbh = pg_connect("dbname=mabase user=postgres password=postgres");Ce deuxième cas est dit "plantant régulièrement" mais le message d'erreur n'est pas indiqué, il serait utile de l'indiquer.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Nous sommes peut être sur une piste. Nous avons découvert que la version de la libpq utilisée par php etait la 8.1.5. Nous sommes en PostgreSQL 8.3.8.
Nous allons tenter la recompil de php avec la libpq de la version 8.3.8.
Nous vous tenons au courant.
Hors ligne
Bonjour,
"Is the server running on host "localhost" and accepting TCP/IP connections on port 5432"
J'avais déjà eu une erreur de ce genre. Elle s'était produite quand j'avais essayé de changer le port du serveur dans le fichier de configuration. Avez-vous changé le port? Est-ce que vous avez apporté des modifications à votre fichier de configuration?
Site web d'un moteur de recherche textuel open-source multi-algorithmes
Je suis un codeur à ses heures perdues.
Hors ligne
Pages : 1