> Unfortunately I just found that we still cannot build in
> thread safety mode on Windows, due to an error on my part -
> specifically, I concentrated on libpq, not realising that
> ecpglib is also thread aware.
>
> It seems that ecpglib uses far more of pthreads than libpq
> does, so our mini implementation used in libpq just won't cut
> it. I've bitten the bullet (well, more of a jelly bean
> actually) and started rewriting things to use the official
> win32 pthreads library, however I ran into an error that I'm
> not sure about:
Yuck. This sucks :-( I was very much hoping we could avoid an other
build *and* runtime dependency. Which will be a cascading runtime
dependency to each and every program that uses libpq. double-:-(
Anyway, one other concern: Do we *know* how this will interact with
win32 native threads? Meaning will a libpq built against the pthreads
library be safe for *native threads*. Because you can definitly expect
most of the win32 apps that need thread-safeness to be usign native
threads - I've so far not come across a single program that's native
win32 that uses pthreads, whereas almost every program written uses
native threads (though most often not in a way that would need a
threadsafe libpq)
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
