Forums PostgreSQL.fr

hfilliere

Membre

Pb de communication entre php5.2 et Postgresql 8.3.8

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

Marc Cousin

Membre

Re : Pb de communication entre php5.2 et Postgresql 8.3.8

- Quel système d'exploitation ?
- Avez vous quelquechose dans les logs postgresql ?

---

Marc.

hfilliere

Membre

Re : Pb de communication entre php5.2 et Postgresql 8.3.8

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)

Marc Cousin

Membre

Re : Pb de communication entre php5.2 et Postgresql 8.3.8

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.

jhashe

Membre

Re : Pb de communication entre php5.2 et Postgresql 8.3.8

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 !

Marc Cousin

Membre

Re : Pb de communication entre php5.2 et Postgresql 8.3.8

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.

hfilliere

Membre

Re : Pb de communication entre php5.2 et Postgresql 8.3.8

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

dverite

Membre

Re : Pb de communication entre php5.2 et Postgresql 8.3.8

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/

hfilliere

Membre

Re : Pb de communication entre php5.2 et Postgresql 8.3.8

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.

Manulion

Membre

Re : Pb de communication entre php5.2 et Postgresql 8.3.8

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.