Search Postgresql Archives

Re: PQstatus does not seem to work

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tim,
 
Thank you for your suggestion.
 
In my application, it is a multi-thread and each thread will need to query 5 select statements. 
 
 
Right now, I am having my own pool of 500 PgConn inside the code.  For each connection that I obtain from the connection pool, I am using direct socket into querying the database, without ODBC.  That way, I can get the data much faster. 
 
Does PGpool II has c api that I can use inside my code? 
 
Also, can I use direct socket connection to query the db with PgpoolI?   The way I am executing query is by using :
 
res = PGexec(conn, "BEGIN");
res = PQexec(pgconn, "DECLARE CURSOR select * ....");
res = PGexec(conn, "END");
 
 
Could someone help me out?  What is the best way for 1) using connectin pooling in my situation and 2) it is the right way to do  BEGIN; DECLARE CURSOR... ; END; for each select query?
 
 
Thanks for all your help.
 
JB

On Tue, Aug 11, 2009 at 2:02 AM, Tim Hart <tjhart@xxxxxxx> wrote:

On 8/10/09 12:08 PM, "Sam Mason" <sam@xxxxxxxxxxxxx> wrote:

> On Tue, Aug 11, 2009 at 12:41:47AM +0800, Juan Backson wrote:
>> I used PQstatus(conn) function to check connection status, but I found that
>> it still returns CONNECTION_OK even after postgres is restarted.  Does
>> anyone know if there is another command that I can use to check connection
>> status?
>
> Yes, PQstatus just gives back the last status.  It doesn't go off and
> check anything.
>
>> What other solution is available to check whether a connection is still
>> alive?
>
> As a connection can go down at any time, this doesn't seem useful.  Just
> send off your request as normal and if it fails because the connection
> was closed then you can open a new one and try again.

Depending on your situation, connection pooling might be a reasonable
option. Instead of managing the connections yourself, you leave that to
another process entirely.

http://www.revsys.com/writings/postgresql-performance.html

Look at the section on "Stateless Applications"

I spend a lot of time writing stateless apps that server many 'users'
concurrently. For me, the pooling idea is much simpler because I only
interact with the 'pool', and the pool manages opening and closing
connections on my behalf.

Of course, this is not a good option if you're writing a stateful app. Your
original email didn't say either way, so this is a take on the other side of
the problem.




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux