Re: Strange error (Socket command option unknown) - Mailing list pgsql-general

From Doug McNaught
Subject Re: Strange error (Socket command option unknown)
Date
Msg-id m3fzqdun78.fsf@varsoon.wireboard.com
Whole thread Raw
In response to Strange error (Socket command option unknown)  (Carlos Moreno <moreno@mochima.com>)
List pgsql-general
Carlos Moreno <moreno@mochima.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


pgsql-general by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: 7.4?
Next
From: Drew Wilson
Date:
Subject: how to detect errors in statements piped to psql?