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;
}
