Re: Strange error (Socket command option unknown)

From: Doug McNaught <doug(at)mcnaught(dot)org>
To: Carlos Moreno <moreno(at)mochima(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Strange error (Socket command option unknown)
Date: 2003-02-25 02:08:11
Message-ID: m3fzqdun78.fsf@varsoon.wireboard.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Carlos Moreno <moreno(at)mochima(dot)com> writes:

> Tom Lane wrote:
>
> >It might be worth logging the whole session between client and
> >server with tcpdump --- that'd be tedious to wade through, but
> >it might give some evidence of what's happening. It seems pretty
> >clear that the client is sending an incomplete message, but knowing
> >only one character of the broken message isn't much to help you
> >debug it. With a tcpdump trace you could see the whole packet ...
> >
>
> Ok, it would look like I am going to have to face the
> terror of doing this! :-)
>
> However, I have zero experience on this; if I may,
> I'd like to ask for some pointers on this tcpdump;
>
> checking the man pages, I came up with:
>
> tcpdump -i local port 5432
>
> I then connected using psql -h localhost, as a test;
> it seems to be showing only timing and length information.
> What could I do?

You'll need to use '-s 1500' (or whatever the MTU is) to get all of
each packet, and '-xX' to dump the whole packet in hex/ascii.

> The other thing is that this is only a quick test to first
> see that I can figure out the information that tcpdump
> gives me... But the connection is not being done through
> TCP/IP, since the application and postmaster are running
> on the same physical machine.
>
> So, how can I listen on local (i.e., AF_UNIX) sockets?
> (which I assume is the way my application and the postgres
> server communicate)

No can do with tcpdump. Either switch your app (temporarily) to use
TCP/IP or look into using strace(1) to log the read/write/send/rcv
calls made by the app (this may be tricky, and will slow down your
app).

The other thing you could do (which would work very well but take some
savvy) is reconfigure PG to use a different port (5433, say), then
write a little daemon that connects to
'/var/run/postgresql/.s.PGSQL.5433' and listens on 's.PGSQL.5432',
passing data both ways and logging it. This would be a great
diagnostic tool but takes some sockets knowledge to write (not
anything super-arcane, though). Switching to TCP temporarily is
probably less work. :)

Hope this helps!

-Doug

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Drew Wilson 2003-02-25 02:29:27 how to detect errors in statements piped to psql?
Previous Message scott.marlowe 2003-02-25 00:46:17 Re: 7.4?