repeatable system index corruption on 7.4.2

I'm seeing the following errors after a few hours of fairly aggressive
bulk load of a database running on Postgres 7.4.2:

cyspec=# select version();
ERROR: root page 43 of "pg_proc_proname_args_nsp_index" has level 0,
expected 2
cyspec=# select * from pg_class;
ERROR: root page 3 of "pg_attribute_relid_attnum_index" has level 0,
expected 1

When I say aggressive, I mean up to 6 simultaneous COPY processes. It is
different from the issue Tom solved the other day in that we don't get
SIGABORT, just corrupt index pages. Here is a backtrace:

#0 errfinish (dummy=0) at elog.c:319
#1 0x081cbc26 in elog_finish (elevel=20, fmt=0x81e6ee0 "root page %u of
\"%s\" has level %u, expected %u")
at elog.c:853
#2 0x0808c632 in _bt_getroot (rel=0x82d58d4, access=1429534320) at
nbtpage.c:287
#3 0x080902f3 in _bt_search (rel=0x82d58d4, keysz=2, scankey=0x8307358,
bufP=0xfeffefa8, access=1) at nbtsearch.c:46
#4 0x08090fea in _bt_first (scan=0x8307198, dir=ForwardScanDirection)
at nbtsearch.c:575
#5 0x0808ed47 in btgettuple (fcinfo=0x82a65cc) at nbtree.c:326
#6 0x081ce5b6 in FunctionCall2 (flinfo=0x0, arg1=136996300,
arg2=136996300) at fmgr.c:993
#7 0x08088329 in index_getnext (scan=0x8307198,
direction=ForwardScanDirection) at indexam.c:503
#8 0x08087951 in systable_getnext (sysscan=0x82a65cc) at genam.c:253
#9 0x081c3c43 in RelationBuildTupleDesc (buildinfo=
{infotype = 2, i = {info_id = 136666169, info_name = 0x8255c39
"pg_index_indrelid_index"}},
relation=0x5a2cdea4) at relcache.c:548
#10 0x081c459f in RelationBuildDesc (buildinfo=
{infotype = 2, i = {info_id = 136666169, info_name = 0x8255c39
"pg_index_indrelid_index"}}, oldrelation=0x0)
at relcache.c:884
#11 0x081c56c0 in RelationSysNameGetRelation (relationName=0x8255c39
"pg_index_indrelid_index") at relcache.c:1637
#12 0x0807febe in relation_openr (sysRelationName=0x8255c39
"pg_index_indrelid_index", lockmode=0) at heapam.c:529
#13 0x08087ab5 in index_openr (sysRelationName=0x8255c39
"pg_index_indrelid_index") at indexam.c:179
#14 0x0808790a in systable_beginscan (heapRelation=0x82ee11c,
indexRelname=0x8255c39 "pg_index_indrelid_index",
indexOK=1 '\001', snapshot=0x0, nkeys=1, key=0xfefff2d0) at genam.c:192
#15 0x081c6f53 in RelationGetIndexList (relation=0x82d846c) at
relcache.c:2717
#16 0x08147bc4 in get_relation_info (relationObjectId=1259,
rel=0x83070d4) at plancat.c:81
#17 0x081492b4 in make_base_rel (root=0x82a65cc, relid=1) at relnode.c:159
#18 0x08148f91 in build_base_rel (root=0x8302164, relid=1) at relnode.c:70
#19 0x0813d5b8 in add_base_rels_to_query (root=0x8302164,
jtnode=0x83070b8) at initsplan.c:86
#20 0x0813e4c9 in query_planner (root=0x8302164, tlist=0x83067a0,
tuple_fraction=0, cheapest_path=0xfefff4e0,
sorted_path=0xfefff4e4) at planmain.c:119
#21 0x0813f03b in grouping_planner (parse=0x8302164, tuple_fraction=0)
at planner.c:897
#22 0x0813e9b4 in subquery_planner (parse=0x8302164, tuple_fraction=0)
at planner.c:315
#23 0x0813e69c in planner (parse=0x8302164, isCursor=0 '\0',
cursorOptions=0) at planner.c:119
#24 0x0816e8ba in pg_plan_query (querytree=0x8302164) at postgres.c:589
#25 0x0816e944 in pg_plan_queries (querytrees=0x830673c, needSnapshot=0
'\0') at postgres.c:656
#26 0x0816eafc in exec_simple_query (query_string=0x8301dbc "select *
from pg_class;\n") at postgres.c:814

Any thoughts? Do you think the patch in 7.4.5 will address this also, or
are we looking at something else?

Thanks,

Joe