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@sss.pgh.pa.us>
To: "Joe Conway" <mail@joeconway.com>
Cc: "Islam Hegazy" <islheg@gawab.com>; <pgsql-general@postgresql.org>
Sent: Friday, June 01, 2007 11:38 PM
Subject: Re: [GENERAL] debugging C functions
> Joe Conway <mail@joeconway.com> 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
