Re: Question about debugging bootstrapping and catalog entries

On 12/18/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Gregory Stark <stark(at)enterprisedb(dot)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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
gurjeet[(dot)singh](at)EnterpriseDB(dot)com
singh(dot)gurjeet(at){ gmail | hotmail | yahoo }.com