From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | jdassen(at)cistron(dot)nl, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Re: PostgreSQL; Strange error |
Date: | 2001-03-20 18:31:19 |
Message-ID: | 11840.985113079@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> writes:
>> Warning: PostgreSQL query failed: FATAL 1: my bits moved
>> right off the end of the world! Recreate index
>> pg_attribute_relid_attnum_index.
> Just use gdb to prevent parent btree page update after
> split and you'll get that error next time when splitting
> new, unpointed from parent, right sibling.
Hmm ... so you think the people who have complained of this are all
working with databases that have suffered previous crash corruption?
I doubt it. There's too much consistency to the reports: in particular,
it's generally triggered by creation of lots of large objects, and it's
always the indexes on pg_attribute, never any other table (even though
large object creation inserts into several system tables). I don't see
how the unfinished-split hypothesis explains that.
My thought was that it is somehow related to the many-equal-keys issues
that we had in 7.0.* and before, and/or the poor behavior for purely
sequential key insertion that we still have. But without a test case
it's hard to be sure.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mikheev, Vadim | 2001-03-20 18:59:16 | RE: Re: PostgreSQL; Strange error |
Previous Message | Tim Frank | 2001-03-20 18:28:21 | RE: Backing up postgresql databases |