On 12/18/06,
Tom Lane <
tgl@sss.pgh.pa.us> wrote:
Gregory Stark <stark@enterprisedb.com> writes:
> Hm, I suppose. Though starting a second gdb is a pain. What I've done in the
> past is introduce a usleep(30000000) in strategic points in the backend to
> give me a chance to attach.
There is already an option to sleep early in backend startup for the
normal case. Not sure if it works for bootstrap, autovacuum, etc,
but I could see making it do so.
You are probably referring to the command-line switch -W to posrgres, that translates to 'PostAuthDelay' GUC variable; I think that kicks in a bit too late! Once I was trying to debug check_root() (called by main() ), and had to resort to my own pg_usleep() to make the process wait for debugger-attach. We should somehow pull the sleep() code into main() as far up as possible.
BTW, here's how I made PG sleep until I attached to it (should be done only in the function you intend to debug):
{
bool waitFor_Debugger = true;
while( waitForDebugger )
pg_usleep(1000000);
}
It will wait forever here, until you set a breakpoint on 'while' and then set the var to false.
The suggestion of single-stepping
initdb will only work well if you have a version of gdb that can step
into a fork, which is something that's never worked for me :-(.
Otherwise the backend will free-run until it blocks waiting for input
from initdb, which means you are still stuck for debugging startup
crashes ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com