From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joseph Shraibman <jks(at)selectacast(dot)net> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: redhat debug info |
Date: | 2007-03-28 16:25:28 |
Message-ID: | 2601.1175099128@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Joseph Shraibman <jks(at)selectacast(dot)net> writes:
> Well 1) I'd like to avoid the performance penalty for including debug
> symbols
There is none. If there were, it would certainly apply to debuginfo
as well --- debuginfo is merely moving the symbols over to a different
file after the compiler finishes.
> and 2) I already built the binary and it is running on a live
> system, and I'd like to get debug symbols w/o restarting.
You're contradicting yourself. You are worried in (1) that the
generated code isn't the same with -g, but in (2) you fantasize
that you could use the symbols to debug code built without it?
If you're willing to assume that that works, you can build ordinary
executables with -g and point gdb to them while attaching to the
existing processes. Personally I wouldn't trust that procedure,
as there are just too many ways to screw it up, and you can waste
a *whole* lot of time trying to gdb with a symbol table that doesn't
match the process's reality...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Jaquay | 2007-03-28 16:39:58 | Re: How does filter order relate to query optimization? |
Previous Message | Stephen Harris | 2007-03-28 16:22:29 | Re: Slow sequential scans on one DB but not another; fragmentation? |