Skip site navigation (1) Skip section navigation (2)

Re: [LibPQ] Trying PQconnectStart: it doesn't seem to connect

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Alessandro Agosto <the(dot)6one6(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [LibPQ] Trying PQconnectStart: it doesn't seem to connect
Date: 2010-01-24 01:58:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
On 23/01/2010 11:52 PM, Alessandro Agosto wrote:
> Hi,
> i'm a python/c developer and i need an asynchronous (python) interface
> to communicate with a database. I like PostgreSQL so i'm trying to write
> a mock-up for a python extension module to use LibPQ in my asynchronous
> programs.

What's wrong with psycopg2 for this purpose?

Python's threading support (in the standard CPython interpreter) is 
awful due to the global interpreter lock. However, it works for waiting 
on blocking sockets as the GIL is released before entering most 
C-language routines. So you should be able to use psycopg2 in dedicated 
I/O worker threads just fine.

If you're trying to use non-blocking sockets and select(...) with libpq, 
well, _then_ you'll have to go outside psycopg2. Be aware, though, that 
using SSL sockets in a non-blocking manner can be ... complicated ... so 
look into that in detail before deciding on this path. Multiple threads 
with blocking connections is likely to be a LOT easier.

Frankly, though, you're never going to get wonderful results out of 
this. Twisted tries, but you've probably seen the issues it has working 
around the GIL and the limited success it has doing so. CPython's GIL 
dooms it to be a pretty shoddy language for high concurrency use, 
whether you use an async socket server model or a blocking threaded model.

> Can someone tell me what i wrong? And if you know some resource that
> explains with an example how i should to verify the connection during
> the select/poll, would be appreciated.

You can't reliably verify that a connection is alive with select/poll. 
TCP/IP timeouts are very long and until the connection times out at the 
TCP/IP level, it might appear fine even though the peer died hours ago.

Craig Ringer

In response to


pgsql-general by date

Next:From: Gauthier, DaveDate: 2010-01-24 04:36:19
Subject: Recursion in triggers?
Previous:From: xu feiDate: 2010-01-24 01:21:35
Subject: FTS uses "tsquery" directly in the query

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group