Re: big text field -> message type 0x44

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

In response to

Responses

Browse pgsql-hackers by date

  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