Re: Question about debugging bootstrapping and catalog

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Gregory Stark <stark(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Question about debugging bootstrapping and catalog
Date: 2006-12-18 14:44:56
Message-ID: 4586A968.60304@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera wrote:
> 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 backtrace. And the debugging log is being
>> spectacularly unhelpful in not telling me where the problem is.
>>
>> 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:
>>
>> creating template1 database in /var/tmp/db7/base/1 ... FATAL: could not create unique index
>> DETAIL: Table contains duplicated values.
>>
>
> One easy thing to try is to use -n (noclean) and then start a standalone
> backend on the borked dir and issue the commands that initdb was feeding
> at that point (usually embedded in the initdb source).
>
>

This step actually runs the BKI file, so it's not embedded in the initdb
code. The other thing with this procedure is to clean up any partial
data left behind first, i.e. clean the global and base/1 directories.
Apart from that it should work fine, I think - probably something like:

gdb postgres
set args -boot -x1 -F -d 5 template1
run < /path/to/bkifile

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-12-18 14:50:12 Re: pg_restore fails with a custom backup file
Previous Message ohp 2006-12-18 14:42:29 Re: unixware and --with-ldap