May I suggest looking at tcpflow? The syntax is similar to tcpdump but it
will create a file for each connection (actually two files, one for inbound
and one for outbound data). The files contain the data stream for that
connection - extremely useful for debugging.
The only thing I've found frustrating is that since one file is everything
from the client and the other is everything from the server you are left to
"synchronize" which parts of the inbound stream correspond to which parts of
the outbound.
If you want a few more bells/whistles and a GUI, try Ethereal.
Cheers,
Steve
On Monday 24 February 2003 2:31 pm, Carlos Moreno wrote:
> Tom Lane wrote:
> >You should look very hard at the part of your code that deals with
> >error reports from the server.
> >
> >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?
>
> 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)
>
> Thanks!
>
> Carlos
