Tom Lane writes:
Lee Kindness [EMAIL PROTECTED] 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
Tom Lane [EMAIL PROTECTED] writes:
Tomas Berndtsson [EMAIL PROTECTED] writes:
After it tries again, it always gets error from recv() for some reason
that I don't know. I also don't understand why errno is set to ENOTTY
at this point, that makes no sense at all.
Are you sure it is set?
Tomas Berndtsson [EMAIL PROTECTED] writes:
Indeed you were right in this. But, if I added -D_REENTRANT to the
Makefile for libpq, it started to set it. If libpq should be thread
safe, I believe it should be compiled with -D_REENTRANT.
When I did this, recv still returns error, but now sets
Tom Lane [EMAIL PROTECTED] writes:
Tomas Berndtsson [EMAIL PROTECTED] writes:
Indeed you were right in this. But, if I added -D_REENTRANT to the
Makefile for libpq, it started to set it. If libpq should be thread
safe, I believe it should be compiled with -D_REENTRANT.
When I did
Tom Lane writes:
Okay, so it seems -D_REENTRANT is the appropriate fix.
We could either add that to the template/solaris file, or just add a
note to FAQ_Solaris advising that it be added to the configure switches
if people intend to use libpq in threaded programs. Is there any
cost
Lee Kindness [EMAIL PROTECTED] writes:
Tom Lane writes:
Okay, so it seems -D_REENTRANT is the appropriate fix.
We could either add that to the template/solaris file, or just add a
note to FAQ_Solaris advising that it be added to the configure switches
if people intend to use
Lee Kindness [EMAIL PROTECTED] writes:
Tom Lane writes:
Okay, so it seems -D_REENTRANT is the appropriate fix.
We could either add that to the template/solaris file, or just add a
note to FAQ_Solaris advising that it be added to the configure switches
if people intend to use
Doug McNaught [EMAIL PROTECTED] writes:
Lee Kindness [EMAIL PROTECTED] writes:
Tom Lane writes:
Okay, so it seems -D_REENTRANT is the appropriate fix.
We could either add that to the template/solaris file, or just add a
note to FAQ_Solaris advising that it be added to the
Lee Kindness [EMAIL PROTECTED] 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
--On Thursday, December 05, 2002 14:02:04 -0500 Tom Lane
[EMAIL PROTECTED] wrote:
Lee Kindness [EMAIL PROTECTED] 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
Tom Lane wrote:
Lee Kindness [EMAIL PROTECTED] 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
Hi, I've been trying to ask on general, and tried to search the
archives without much result, so I'll try here.
I'm using PostgreSQL 7.2.1 on Solaris 8/sparc. In a table, I have a
text field, which may contain long ascii strings. However, when trying
to put data larger than about 32000 characters
Tom Lane [EMAIL PROTECTED] writes:
Tomas Berndtsson [EMAIL PROTECTED] writes:
Since it works in psql, it must be possible for my application to work
too, but I just can't figure out why it doesn't.
I think it's got to be a bug in your application code.
A bug in libpq is the only other
Tomas Berndtsson [EMAIL PROTECTED] writes:
Yep, there is only one installation of PostgreSQL on the machine. My
application is multithreaded, and I have been very careful to open a
new connection for each thread. Could it have anything to do with
semaphores and shared memory in Solaris?
I
Tom Lane [EMAIL PROTECTED] writes:
Tomas Berndtsson [EMAIL PROTECTED] writes:
Yep, there is only one installation of PostgreSQL on the machine. My
application is multithreaded, and I have been very careful to open a
new connection for each thread. Could it have anything to do with
Tomas Berndtsson [EMAIL PROTECTED] writes:
However, after some semi-random looking through the source code of
libpq, I tried to change a value, namely here:
fe-misc.c row 510 in pqReadData():
if (conn-inEnd 32768
(conn-inBufSize - conn-inEnd) = 8192)
Tom Lane [EMAIL PROTECTED] writes:
Tomas Berndtsson [EMAIL PROTECTED] writes:
However, after some semi-random looking through the source code of
libpq, I tried to change a value, namely here:
fe-misc.c row 510 in pqReadData():
if (conn-inEnd 32768
Tomas Berndtsson [EMAIL PROTECTED] writes:
After it tries again, it always gets error from recv() for some reason
that I don't know. I also don't understand why errno is set to ENOTTY
at this point, that makes no sense at all.
Are you sure it is set? Try setting errno=0 just before recv()
Tom Lane wrote:
Tomas Berndtsson [EMAIL PROTECTED] writes:
After it tries again, it always gets error from recv() for some reason
that I don't know. I also don't understand why errno is set to ENOTTY
at this point, that makes no sense at all.
Are you sure it is set? Try setting errno=0
19 matches
Mail list logo
