Zdenek Kotala wrote:
Gregory Stark wrote:
"Martijn van Oosterhout" <kleptog@svana.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.
There is dtrace script which "sitting" on exec. It stops postgres
process after exec. It works on Solaris. Different name of kernel
function probably will be on other platform where is dtrace implemented
(Freebsd,MacOS).
::exec_common:return
/execname == "initdb"/
{
exec_pg = 1;
}
syscall:::entry
/execname == "postgres" && exec_pg == 1/
{
stop();
printf("Postgres is stopped.\n");
exec_pg = 0;
}
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
