Re: [HACKERS] still getting FATAL errors on btree's...

On Mon, 13 Apr 1998, The Hermit Hacker wrote:

> On Mon, 13 Apr 1998, Bruce Momjian wrote:
>
> > >
> > >
> > > I'm still getting the following BTP_CHAIN errors on my btree index. Funny
> > > thing is that its the *same* index each time, and this is after dropping
> > > and rebulding it...
> > >
> > > ...where next to investigate? Recommendations? IMHO, this is critical
> > > enough to hold off a v6.3.2 release :(
> >
> > Obiously there is something strange going on, or many more people would
> > be seeing it. The question is what.
> >
> > Could it be the data? Concentrate on that table, load only half, and
> > see if it happens. Try loading first half of the file twice, to the
> > file is the same size, but the data is only from the first half. Try it
> > with the second half too. Does the problem change. If so, there is
> > something in the data that is causing the problem.
>
> Well, I kinda figured it had something to do with the data, but
> narrowing it down (500+k records) is something that isn't that easy :(
>
> I know its the radhist_userid index, which is indexed on one
> field, userid...if there was some way of translating location in the index
> with a record number...?
>
> Oh well...will continue to investigate and use your ideas...

This is very quickly doing downhill ;(

I took all entries in radhist newer then 01/01/98 and copied them into
radnew, then deleted those entries (first bad move), then I did an 'alter
table' to move radhist to radhist_old, and another 'alter table' to move
radnew back to radhist...

Totally locked up postmaster, so I had to kill off the processes (second
bad move)...

ls -lt rad*
-rw------- 1 postgres wheel 77144064 Apr 13 13:10 radhist_old
-rw------- 1 postgres wheel 3842048 Apr 13 13:08 radlog
-rw------- 1 postgres wheel 1073152 Apr 13 13:07 radlog_userid
-rw------- 1 postgres wheel 1646592 Apr 13 13:07 radlog_uniq_id
-rw------- 1 postgres wheel 999424 Apr 13 13:07 radlog_stop_time
-rw------- 1 postgres wheel 1294336 Apr 13 13:07 radlog_start_time
-rw------- 1 postgres wheel 36921344 Apr 13 12:55 radhist
-rw------- 1 postgres wheel 6864896 Apr 6 10:14 radold

Now, I can't access radhist, even though the database is there:

acctng=> select * from radhist;
ERROR: radhist: Table does not exist.

Checked the pg_class table, and radnew still existed, but radhist didn't,
so did the following to "fix" it...

update pg_class set relname = 'radhist' where relname = 'radnew';

Any particular reason why that was a bad idea? I appears to have
worked...