Обсуждение: Is libpq re-entrant?

Dear Hackers,

Can anyone confirm for me that libpq is re-entrant. Ie, it is safe to
execute libpq calls from within a signal handler when that signal could've
interrupted a libpq function? Of course I don't expect to be able to use
the same PGconn or PGresult structures inside the signal handler as
outside.

I've looked through the 6.4.2 libpq documentation and it doesn't say,
although the existence of non-blocking calls implies it could be made
re-entrant quite easily.

Many thanks
Ian

Ian Grant <I.A.N.Grant@damtp.cam.ac.uk> writes:
> Can anyone confirm for me that libpq is re-entrant. Ie, it is safe to
> execute libpq calls from within a signal handler when that signal could've
> interrupted a libpq function? Of course I don't expect to be able to use
> the same PGconn or PGresult structures inside the signal handler as
> outside.

Operations on a single PGconn are definitely not thread-safe, but I
think you could use multiple PGconns from different threads without
trouble.  The only gotcha I know of offhand is that PQconnectdb()
is not thread-safe because of use of a modifiable static data structure.
Fixing that seems to require changing the API, so I haven't done
anything about it yet.

Of course this assumes that your underlying libc is thread-safe;
if malloc(), sprintf(), et al are not thread-safe then better
forget the whole thing.

There is a special exception for PQrequestCancel, which is supposed
to be safely callable from a signal handler even if your libc is
brain-dead.

If you try it and find any other problems let me know; I'll see if
I can do anything about them.
        regards, tom lane