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 referring to the
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 an
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
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
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 alredy know
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
On 12/18/06, Martijn van Oosterhout kleptog@svana.org 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
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 and
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
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
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
be postgres.org $*.
- Original Message -
From: Takayuki Tsunakawa [EMAIL PROTECTED]
To: Gregory Stark [EMAIL PROTECTED]; PostgreSQL Hackers
pgsql-hackers@postgresql.org
Sent: Tuesday, December 19, 2006 9:37 AM
Subject: Re: [HACKERS] Question about debugging bootstrapping and
catalog entries
Hello
12 matches
Mail list logo
