Обсуждение: PHP + PDO + PGPOOL = Segmentation fault

Hello, I have a script which is written in PHP (5.2.8) + PDO (1.0.3). It's stable, but actual version of PGSQL driver for PDO don't allow persistent connections. So we decided to use PGPOOL-II-2.2.5. It's configured to work in connection pool mode with following settings: # number of pre-forked child process (I know it's many, but we test from 32 till 256) num_init_children = 256 # Number of connection pools allowed for a child process (tested from 2 till 10) max_pool = 2 # If idle for this many seconds, child exits. 0 means no timeout. child_life_time = 300 # If idle for this many seconds, connection to PostgreSQL closes. # 0 means no timeout. connection_life_time = 30 # If child_max_connections connections were received, child exits. # 0 means no exit. child_max_connections = 0 # If client_idle_limit is n (n > 0), the client is forced to be # disconnected whenever after n seconds idle (even inside an explicit # transactions!) # 0 means no disconnect. client_idle_limit = 10 no replication or parallel query support enabled. When our script establish connection to PGPOOL, it can work well or can fail with "Segmentation fault". Measurement shows that 40% of script executions failed with "Segmentation fault" and always under heavy stress. Does anyone faced with such problem?

---

View this message in context: PHP + PDO + PGPOOL = Segmentation fault
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

VladK wrote:
> Hello,
>
> I have a script which is written in PHP (5.2.8) + PDO (1.0.3). It's stable,
> but actual version of PGSQL driver for PDO don't allow persistent
> connections.
>
> So we decided to use PGPOOL-II-2.2.5. It's configured to work in connection
> pool mode with following settings:

PHP doesn't really do connection pools anyway. You would have ended up
with one connection for each Apache backend.

> When our script establish connection to PGPOOL, it can work well or can fail
> with "Segmentation fault". Measurement shows that 40% of script executions
> failed with "Segmentation fault" and always under heavy stress.

What fails with "segmentation fault" - Apache+PHP, pgpool or PostgreSQL?

--
  Richard Huxton
  Archonet Ltd

I assume you get segfault of pgpool.
Can you take a coredump and backtrace? That will be very helpfull to
inspect your problem.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> Hello,
>
> I have a script which is written in PHP (5.2.8) + PDO (1.0.3). It's stable,
> but actual version of PGSQL driver for PDO don't allow persistent
> connections.
>
> So we decided to use PGPOOL-II-2.2.5. It's configured to work in connection
> pool mode with following settings:
>
> # number of pre-forked child process (I know it's many, but we test from 32
> till 256)
> num_init_children = 256
>
> # Number of connection pools allowed for a child process (tested from 2 till
> 10)
> max_pool = 2
>
> # If idle for this many seconds, child exits.  0 means no timeout.
> child_life_time = 300
>
> # If idle for this many seconds, connection to PostgreSQL closes.
> # 0 means no timeout.
> connection_life_time = 30
>
> # If child_max_connections connections were received, child exits.
> # 0 means no exit.
> child_max_connections = 0
>
> # If client_idle_limit is n (n > 0), the client is forced to be
> # disconnected whenever after n seconds idle (even inside an explicit
> # transactions!)
> # 0 means no disconnect.
> client_idle_limit = 10
>
> no replication or parallel query support enabled.
>
> When our script establish connection to PGPOOL, it can work well or can fail
> with "Segmentation fault". Measurement shows that 40% of script executions
> failed with "Segmentation fault" and always under heavy stress.
>
> Does anyone faced with such problem?
> --
> View this message in context:
http://www.nabble.com/PHP-%2B-PDO-%2B-PGPOOL-%3D-Segmentation-fault-tp26071405p26071405.html
> Sent from the PostgreSQL - general mailing list archive at Nabble.com.

depends on how your PHP module is compiled for instance
taking a borland compiled module for Apache (mod_php) and forcing it to work on Unix which has a different memory model would cause segfault
so we would need to know the specifics of
deployed platform
OS
Compiler version
to determine the cause of this error

greetings
Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.

> Date: Wed, 28 Oct 2009 09:25:53 +0900
> To: vladimir.klykov@gmail.com
> CC: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] PHP + PDO + PGPOOL = Segmentation fault
> From: ishii@postgresql.org
>
> I assume you get segfault of pgpool.
> Can you take a coredump and backtrace? That will be very helpfull to
> inspect your problem.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
>
> > Hello,
> >
> > I have a script which is written in PHP (5.2.8) + PDO (1.0.3). It's stable,
> > but actual version of PGSQL driver for PDO don't allow persistent
> > connections.
> >
> > So we decided to use PGPOOL-II-2.2.5. It's configured to work in connection
> > pool mode with following settings:
> >
> > # number of pre-forked child process (I know it's many, but we test from 32
> > till 256)
> > num_init_children = 256
> >
> > # Number of connection pools allowed for a child process (tested from 2 till
> > 10)
> > max_pool = 2
> >
> > # If idle for this many seconds, child exits. 0 means no timeout.
> > child_life_time = 300
> >
> > # If idle for this many seconds, connection to PostgreSQL closes.
> > # 0 means no timeout.
> > connection_life_time = 30
> >
> > # If child_max_connections connections were received, child exits.
> > # 0 means no exit.
> > child_max_connections = 0
> >
> > # If client_idle_limit is n (n > 0), the client is forced to be
> > # disconnected whenever after n seconds idle (even inside an explicit
> > # transactions!)
> > # 0 means no disconnect.
> > client_idle_limit = 10
> >
> > no replication or parallel query support enabled.
> >
> > When our script establish connection to PGPOOL, it can work well or can fail
> > with "Segmentation fault". Measurement shows that 40% of script executions
> > failed with "Segmentation fault" and always under heavy stress.
> >
> > Does anyone faced with such problem?
> > --
> > View this message in context: http://www.nabble.com/PHP-%2B-PDO-%2B-PGPOOL-%3D-Segmentation-fault-tp26071405p26071405.html
> > Sent from the PostgreSQL - general mailing list archive at Nabble.com.
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

---

Windows 7: It helps you do more. Explore Windows 7.

This script executed by cron. And segmentation fault generated by PHP script.

Richard Huxton wrote:
>
> PHP doesn't really do connection pools anyway. You would have ended up
> with one connection for each Apache backend.
> ....
> What fails with "segmentation fault" - Apache+PHP, pgpool or PostgreSQL?
>
>   Richard Huxton
>   Archonet Ltd
>
>

--
View this message in context:
http://www.nabble.com/PHP-%2B-PDO-%2B-PGPOOL-%3D-Segmentation-fault-tp26071405p26088267.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

VladK wrote:
> This script executed by cron. And segmentation fault generated by PHP
> script.

In that case you have a bug in one of: Apache, PHP, PDO libraries.

If the PDO libraries use PostgreSQL's libpq library then that could be
involved too.

Even if pgpool has a bug and isn't communicating correctly with the PHP
code it shouldn't be possible to cause a segfault.

Your best bet is to see if you can reduce it to as simple a test as
possible. Then we can see what to do next. This may involve working with
the PDO / PHP groups.

--
  Richard Huxton
  Archonet Ltd