From: | "Mason Hale" <masonhale(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Duplicate values found when reindexing unique index |
Date: | 2007-12-31 22:51:02 |
Message-ID: | 8bca3aa10712311451k6814c29x2be5625d4fbd2189@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hello Tom --
a thousand thanks for taking the time to walk through those files.
This could be the kernel's fault, but I'm wondering whether the
> RAID controller is going south. Offhand it seems like the controller
> would be the only place that would be likely to explain both the
> bogus-data and good-data-in-wrong-place behaviors.
>
To clarify a bit further -- on the production server, the data is written to
a 10-disk RAID 1+0, but the pg_xlog directory is symlinked to a separate,
dedicated SATA II disk.
There is a similar setup on the standby server, except that in addition to
the RAID for the data, and a separate SATA II disk for the pg_xlog, there is
another disk (also SATA II) dedicated for the archive of wal files copied
over from the production server.
I mention all this because if the problem is the wal files in the pg_xlog
directory becoming corrupted, and those exist on a dedicated disk (not in a
RAID), then doesn't that indicate that the RAID controller is not involved?
Mason
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-12-31 23:35:26 | Re: Duplicate values found when reindexing unique index |
Previous Message | Tom Lane | 2007-12-31 22:16:19 | Re: Duplicate values found when reindexing unique index |