Re: [HACKERS] Is libpq re-entrant?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Is libpq re-entrant? |
Дата | |
Msg-id | 20155.917895619@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Is libpq re-entrant? (Ian Grant <I.A.N.Grant@damtp.cam.ac.uk>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: