| From: | Joe Conway <mail(at)joeconway(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: repeatable system index corruption on 7.4.2 |
| Date: | 2004-08-19 21:49:13 |
| Message-ID: | 41252059.2060408@joeconway.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Simon Riggs wrote:
>>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).
This is fairly high end hardware -- 4 hyperthreaded CPUs (hence 8 CPUs
from the OS perspective), 8GB RAM.
But in any case, since last report we've reproduced the problem with a
single COPY at a time.
> 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?
This is an initial data load, coming from an export from a large
cOmmeRciAl database. No other activity other than loading, no inserts.
The total rows to be imported into Postgres is ~900 million -- that's
why we would like to do as much in parallel as possible.
Joe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2004-08-19 21:56:41 | Re: repeatable system index corruption on 7.4.2 |
| Previous Message | Josh Berkus | 2004-08-19 21:42:26 | Re: [PATCHES] Postgresql.conf Documentation change |