From: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Question about debugging bootstrapping and catalog |
Date: | 2006-12-18 14:13:06 |
Message-ID: | 4586A1F2.7030906@sun.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark wrote:
> "Martijn van Oosterhout" <kleptog(at)svana(dot)org> writes:
>
>> Here's what I did: you can step over functions in initdb until it fails
>> (although I alredy know which part it's failing I guess). Restart. Then
>> you go into that function and step until the new backend has been
>> started. At this point you attach another gdb to the backend and let it
>> run.
>
> 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.
I use dtrace which wait on write syscall for stderr output and if it is
happen then stop(freeze) the process and I able to connect into the
process with debugger and examine what happened.
Zdenek
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2006-12-18 14:39:37 | Re: pg_restore fails with a custom backup file |
Previous Message | Alvaro Herrera | 2006-12-18 13:03:34 | Re: Question about debugging bootstrapping and catalog entries |