Thanks for your replies, they were very helpful to me. Unfortuantely, I
can't trace the C function. PostgreSQL returns the results directly and the
debugger doesn't stop at the breakpoints in the C function.
I think the problem is in the pointers. I use pointers in my function and I
defined them as static to be preserved between calls, my function returns a
set of records. When I comment the pointers portion, the function works
well. But with the pointers, it hangs.
Any idea on how to deal with pointers issue?
Regards
Islam Hegazy
----- Original Message -----
From: "Tom Lane" <tgl@xxxxxxxxxxxxx>
To: "Joe Conway" <mail@xxxxxxxxxxxxx>
Cc: "Islam Hegazy" <islheg@xxxxxxxxx>; <pgsql-general@xxxxxxxxxxxxxx>
Sent: Friday, June 01, 2007 11:38 PM
Subject: Re: [GENERAL] debugging C functions
Joe Conway <mail@xxxxxxxxxxxxx> writes:
[ much good advice snipped, but I have to weigh in on one point ]
4. Start another console and determine the PID for the backend
session (this will wrap poorly -- I'll do my best to make it
readable)
"select pg_backend_pid()" is another alternative for finding the PID.
Personally I've gotten to the point where manually determining the
backend PID at all is tedious, and so I tend to use this script:
#!/bin/sh
# tee /dev/tty is for user to see the set of procs considered
PROCS=`ps auxww | \
grep postgres: | \
grep -v -e 'grep postgres:' -e 'postgres: stats' -e 'postgres:
writer' -e 'postgres: archiver' -e 'postgres: logger' | \
tee /dev/tty | \
awk '{print $2}'`
if [ `echo "$PROCS" | wc -w` -eq 1 ]
then
exec gdb $PGINSTROOT/bin/postgres -silent "$PROCS"
else
exec gdb $PGINSTROOT/bin/postgres -silent
fi
This fails (but gives you a list of processes to consider attaching to)
if there's more than one candidate.
regards, tom lane
