"Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> On 12/18/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> 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 referr
On 12/18/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
> Hm, I suppose. Though starting a second gdb is a pain. What I've done in
the
> past is introduce a usleep(3000) in strategic points in the backend
to
> give me a chance to attach.
There is already a
tgres $*
Sorry, this should be postgres.org $*.
- Original Message -
From: "Takayuki Tsunakawa" <[EMAIL PROTECTED]>
To: "Gregory Stark" <[EMAIL PROTECTED]>; "PostgreSQL Hackers"
Sent: Tuesday, December 19, 2006 9:37 AM
Subject: Re: [HACKERS]
Hello, Mr. Stark
> Are there any tricks people have for debugging bootstrapping
processing? I
> just need to know what index it's trying to build here and that
should be
> enough to point me in the right direction:
As Mr. Lane says, it would be best to be able to make postgres sleep
for an arbitr
Gregory Stark <[EMAIL PROTECTED]> writes:
> Hm, I suppose. Though starting a second gdb is a pain. What I've done in the
> past is introduce a usleep(3000) 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
n
Gregory Stark wrote:
>
> I've been fooling with catalog entries here and I've obviously done something
> wrong. But I'm a bit frustrated trying to debug initdb. Because of the way it
> starts up the database in a separate process I'm finding it really hard to
> connect to the database and get a ba
On Mon, Dec 18, 2006 at 12:59:28PM +0100, Zeugswetter Andreas ADI SD wrote:
> How do you attach fast enough, so not all is over before you are able to
> attach ?
> I'd like to debug initdb failure on Windows (postgres executable not
> found) when
> running make check with disabled is_admin check a
On 12/18/06, Martijn van Oosterhout wrote:
If you get an error, you put a breakpoint on errfinish(). Note, that
gets called even on messages you don't normally see, so you may have to
skip a couple to get the real message.
You wouldn't need to skip anything if you put the breakpoint inside t
"Martijn van Oosterhout" 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
> > Are there any tricks people have for debugging bootstrapping
processing? I
> > just need to know what index it's trying to build here and that
should be
> > enough to point me in the right direction:
>
> Here's what I did: you can step over functions in initdb until it
fails
> (although I alr
On Mon, Dec 18, 2006 at 11:35:44AM +, Gregory Stark wrote:
> Are there any tricks people have for debugging bootstrapping processing? I
> just need to know what index it's trying to build here and that should be
> enough to point me in the right direction:
Here's what I did: you can step over
I've been fooling with catalog entries here and I've obviously done something
wrong. But I'm a bit frustrated trying to debug initdb. Because of the way it
starts up the database in a separate process I'm finding it really hard to
connect to the database and get a backtrace. And the debugging log
12 matches
Mail list logo
