From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Grzegorz Piotr Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: _penalty gist method invoked with one key NULL |
Date: | 2005-10-27 21:44:24 |
Message-ID: | 24328.1130449464@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Grzegorz Piotr Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> writes:
> can I just run postgres, in non forking mode, on gdb?
Just start a normal session and then attach to the backend process with
gdb in a separate window. There's no reason to fool with a standalone
backend for 99.99% of debugging problems. With a regular session, you
can use psql to input the SQL commands, which is MUCH friendlier than a
standalone backend, and you can run additional sessions in case you'd
like to examine the state of the database while you've got your debug
backend pinned down someplace.
I tend to use the attached script so that I don't even need to manually
discover the PID to attach to, assuming there's only one backend running
(else it shows me all the plausible candidates to attach to).
Dunno about the gist-specific issue, Oleg or Teodor will have to answer
that.
regards, tom lane
#!/bin/sh
# Usage: gdblive
# 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2005-10-27 21:44:30 | Re: ERROR: invalid memory alloc request size <a_big_number_here> |
Previous Message | Kevin Murphy | 2005-10-27 21:42:45 | Re: [GENERAL] aix build question re: duplicate symbol warning |