| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Magnus Hagander <mha(at)sollentuna(dot)net>, Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Win32 Thread safetyness |
| Date: | 2005-08-28 19:22:32 |
| Message-ID: | 26151.1125256952@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Magnus Hagander wrote:
>>> Also, there doesn't seem to be a good way for users to know
>>> if libpq or ecpg was compiled to be thread-safe.
>>
>> Right. A runtime function for this might be a good thing? Like "bool
>> PQisThreadSafe()" or such?
> Yes, and a flag to ecpg. Added to TODO:
Um, it's not clear *when* you need to know this:
- application configure time?
- application compile time?
- application link time?
- application run time?
Of those possibilities, "add a function" responds to only one, and it's
the one I can see least use-case for. I should think that by run-time
it's probably too late to do much about it other than fail.
You can find out whether thread-safety was mentioned in our configure
settings by looking at the result of pg_config --configure. This might
be enough for the find-out-at-configure-time case.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andreas Pflug | 2005-08-28 20:23:31 | dangling lock information? |
| Previous Message | Dave Page | 2005-08-28 19:11:42 | Re: Win32 Thread safetyness |