From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Berndtsson <tomas(at)nocrew(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: big text field -> message type 0x44 |
Date: | 2002-12-04 20:16:00 |
Message-ID: | 17900.1039032960@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tomas Berndtsson <tomas(at)nocrew(dot)org> 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 wouldn't think so; the client-side code doesn't have anything to do
with either shared memory or semaphores. But your comment about
threading immediately focuses my attention on that.
Let's see (checks ASCII codes...) message 0x44 is 'D' which is a data
message. The only situations I've seen before in which libpq comes out
with this complaint are (1) when it's lost sync with the backend as a
result of running out of memory to store a large query result (its
recovery from that situation is pretty crummy :-(), or (2) when
someone's confused libpq by trying concurrent queries with one PGconn.
You say you didn't do (2), so that leaves (1). Is it possible that your
threading setup limits the amount of memory libpq can malloc?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Berndtsson | 2002-12-04 20:43:48 | Re: big text field -> message type 0x44 |
Previous Message | Marc G. Fournier | 2002-12-04 20:03:59 | Re: [GENERAL] PostgreSQL Global Development Group Announces |