Thanks Jason, I think I had read that - I quite enjoy Edward's posts. Re-reading, seems to confirm what I thought, most (all?) of the FFI calls in HDBC-postgresql should be changed to "safe". -- David On Thu, Sep 2, 2010 at 2:47 PM, Jason Dagit wrote:

...

Greetings,

I'm having an issue with the HDBC-postgresql package that requires me to manually patch it before installation for most of my use cases.

All the FFI calls in this package are marked "unsafe". Unfortunately,

On Wed, Sep 1, 2010 at 7:40 PM, David Powell wrote: this

...

means that whenever I issue a slow sql query, all other processing stops. In most places that I want to use this module, I've had to manually patch it to at least mark the PQexec and PQexecParams calls as "safe".

Is there any reason these calls should not be marked as "safe"? I understand that there a little extra runtime overhead with this, but I'd have thought that negligible given all the other processing that goes on with these particular calls under the hood.

Have you read this? http://blog.ezyang.com/2010/07/safety-first-ffi-and-threading/

Perhaps it answers your questions?

Jason

On Thu, Sep 2, 2010 at 1:00 AM, David Powell wrote:

Thanks Jason, I think I had read that - I quite enjoy Edward's posts. Re-reading, seems to confirm what I thought, most (all?) of the FFI calls in HDBC-postgresql should be changed to "safe".

Wouldn't that require thread safety on the part of libpq? Versions 8.4 and earlier requires the library to be configured with the option --enable-thread-safety, although version 9.0 has thread safety turned on by default. http://www.postgresql.org/docs/8.4/static/libpq-threading.html http://www.postgresql.org/docs/9.0/static/libpq-threading.html At least the Ubuntu PostgreSQL 8.4 packages are compiled with thread safety, but I can't speak for other distributions. Best, Leon

Hi John, My current usage of hdbc is in a server process that takes requests from multiple clients, queries the database, and returns a result. Having a single db query block everything else isn't really workable for me. I suspect this will also be an issue for others. As an example, the persistent-postgresql package which is part of the new Yesod web framework will have the same problem. I can send you a patch, but I am concerned with the issue Leon raised about libpq needing to be compiled with thread support. This is the default on my platforms (macosx, debian), but probably is dangerous to rely on. I guess we can just test the result of 'PQisthreadsafe()', in connectPostgreSQL and raise an error if it is false. Cheers, -- David On Fri, Sep 3, 2010 at 1:36 AM, John Goerzen wrote:

Hi David,

I've had varying arguments from people that want me to mark things safe or unsafe for various performance reasons. I'm happy to apply your change if you like. Can you send me a diff (and attach your explanation here to it, which I'll use as a commit message for future reference)?

Thanks,

-- John

On 09/01/2010 09:40 PM, David Powell wrote:

...

Greetings,

I'm having an issue with the HDBC-postgresql package that requires me to manually patch it before installation for most of my use cases.

All the FFI calls in this package are marked "unsafe". Unfortunately, this means that whenever I issue a slow sql query, all other processing stops. In most places that I want to use this module, I've had to manually patch it to at least mark the PQexec and PQexecParams calls as "safe".

Is there any reason these calls should not be marked as "safe"? I understand that there a little extra runtime overhead with this, but I'd have thought that negligible given all the other processing that goes on with these particular calls under the hood.

Cheers,

-- David Powell