> 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