Re: big text field -> message type 0x44

Tom Lane writes:
> Lee Kindness <lkindness(at)csl(dot)co(dot)uk> writes:
> > Tom Lane writes:
> >>> Okay, so it seems -D_REENTRANT is the appropriate fix.
> > However, _REENTRANT is not a Solarisism... On all (recent) UNIX
> > systems it toggles on correct handling for thread specific instances
> > of historically global variables (eg errno). It should be considered
> > for all platforms if libpq is intended to be used from threaded
> > programs.
> Now that I think about it, what that macro is probably really doing is
> switching the code from looking at a static "errno" variable to looking
> at a per-thread variable. So in fact -D_REENTRANT would be correct if
> you intended to link with a thread-aware libc, and wrong if you intended
> to link with a non-aware libc. (Is there such a thing as a non-threaded
> implementation of libc on the platforms where -D_REENTRANT does
> anything?) If this analysis is right then I think we should *not*
> force _REENTRANT; it will have to be up to users to choose the mechanism
> they want to use in their programs.

I think in the long-term the libraries are going to have to be looked
at in detail to ensure they work as would be expected from
multithreaded programs. I cannot see any harm in adding -D_REENTRANT
to CFLAGS even though some platforms supersede it with -lthread or
something (becaue they still define _REENTRANT behind the scenes).

I remember in the past reading in detail the issues involved with
making shared libraries work as expected from threads. However I
no-longer has access to that book, but think it was "Multithreaded
Programming with Pthreads"...

Again, something i'd like to look at later this month. Workwise the
threaded code we had which used embedded SQL calls in C fell into
heaps when moved from Ingres to PostgreSQL. And Ingres's ESQL/C is
real crap for threading and we employeed loads of mutexes... So, ...

Lee.