Re: repeatable system index corruption on 7.4.2

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

> 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.

OK, problem accepted, but why would you run 6 simultaneous COPYs? Presumably
on > 1 CPU? Sounds like you're hitting the right edge of the index really
hard (as well as finding a hole in the logic).

Can you stream the data to a shared pipe and run just a single COPY?
Could you "dilute" the index by adding an irrelevant number as the first
column on the index, so that the index hotspot moves to 6 places? Or  use a
functional index to alter the distribution of values?
You'd be quite likely to see an improvement in performance by avoiding the
contention, and that may be a good workaround for now.

Can I ask, are you also running simultaneous INSERTs or just COPYs? And
presumably you're mixing that with SELECTs that are doing index scans? Does
the table have random deletes on it, or just occaisional regular bulk
deletes? How often is it VACUUMed?

Best Regards, Simon Riggs