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

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).

/execname == "initdb"/
  exec_pg = 1;

/execname == "postgres" && exec_pg == 1/
  printf("Postgres is stopped.\n");
  exec_pg = 0;

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to