Skip site navigation (1) Skip section navigation (2)

Re: Question about debugging bootstrapping and catalog

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-20 21:05:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Zdenek Kotala wrote:
> 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.

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 

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

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

In response to

pgsql-hackers by date

Next:From: Russell SmithDate: 2006-12-20 21:23:49
Subject: Re: column ordering, was Re: [PATCHES] Enums patch v2
Previous:From: Inaam RanaDate: 2006-12-20 20:29:30
Subject: Re: Load distributed checkpoint

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group