Re: LOG: unexpected EOF within message length word

On Sat, Sep 03, 2005 at 11:31:19AM +0530, Mavinakuli, Prasanna (STSD) wrote:
> 1) I am using postgres 7.4 version.

Exactly which version?  What does "SELECT version()" show?  Did you
build PostgreSQL from source yourself, or did you install a pre-built
package?  Have you tried a newer version like 8.0.3 or 8.1beta1?

> 2)I have sent tusc o/p along with first mail.however I will attch it
> once again.

I don't see that output in any of your earlier messages, nor does
it show up in the copy in the list archives:

http://archives.postgresql.org/pgsql-general/2005-09/msg00077.php

No matter; I see the output in this message, although it doesn't
appear to be from the code you posted (the output shows text messages
that don't appear in the posted code).

> 3)the following code works fine in HP-UX PA machines.but not in HP-UX IA
> machines.
>   I meant the maxiumum data that we can insert into IA machines
>   is 40760.if we make it to 40764 then the code breaks.

How does the code behave in each of the following scenarios?

1. PA client connecting to PA server.
2. PA client connecting to IA server.
3. IA client connecting to PA server.
4. IA client connecting to IA server.

If anybody else is following this thread, have you experienced or
heard of problems with HP-UX IA before?

> 4)I have changed default setting and made it as TCP
>   still problem persists.
>   Cud u please eloborate more on this topic(using TCP vs Unix Socket)

The connection type might not matter; I was just wondering if you
had checked whether it did and if you had seen anything unusual in
a packet sniff.

> send(4, "P \0\0\0u \0i n s e r t   i n t ".., 98304, 0)
> ................................................................ = 40960

Here libpq attempts to write 98304 bytes but only 40960 bytes were
written; the pqSendSome() function within libpq will wait for the
socket to become writable before sending the rest.

> sigaction(SIGPIPE, 0x9fffffffffff0080, 0x9fffffffffff00b0)
> ............................................................. = 0
> recv(4, 0x600000000007acc0, 16384, 0)
> ........................................................................
> .......... ERR#11 EAGAIN
> poll(0x9fffffffffff00d0, 1, -1)
> ........................................................................
> ................ [sleeping]
> ksleep(PTH_CONDVAR_OBJECT, 0x9fffffffef7de4b8, 0x6000000000059388, NULL)
> ............................................... [sleeping]
>
> After it goes forever sleep*****.

Apparently the socket never becomes writable, or at least not for
as long as you waited.  How long did you wait before killing the
client?  What does a trace on the server process show when the
client is blocked?  What does a trace of the same client code on a
PA machine (one that works) show?

--
Michael Fuhr