> 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. I saw this error after PG' crashes and power off in my employer' project where large objects were not used. As for pg_attributes - PG inserts into this table more rows than into others => more splits => higher probability of unfinished split in the event of crash. > 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 pg_attribute_relid_attnum_index is unique index, so I doubt that "many-equal-keys issue" is related to subj. > sequential key insertion that we still have. But without a test case > it's hard to be sure. This is hypothesis and we don't know how to test it. But unfinished splits is not hypothesis. It's *obviously* may cause "my bits moved right off the end of the world" error and we can test this very easy. Vadim ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])