Martijn,
What I didn't think to mention in my original post is that I was unable to
delete the rows because the backend would crash.
It turned that the table was way beyond help (at least by someone at my
skill level), because there was some bad memory in the machine. Thanks for
the pointer to memtest86. It did the trick.
Thanks,
Peter Darley
-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org]On Behalf Of Martijn van
Oosterhout
Sent: Tuesday, July 02, 2002 5:58 PM
To: Peter Darley
Cc: Pgsql-General
Subject: Re: [GENERAL] Bad records in table
On Tue, Jul 02, 2002 at 08:15:01AM -0700, Peter Darley wrote:
> I can identify the bad records with a simple perl script that reads all
the
> records sequentially and lets me know which ones crash the back end. Now
> that I know which ones they are, how can I get rid of them?
If you know which tuple it is that kills it, you can delete it. That should
be sufficient. If you know the ctid or oid, they're good keys for this sort
of thing.
> Once I get this all fixed, what kinds of tests should I do on the machine
> to see if it's got some kind of hardware problem? It's RedHat Linux
> 2.4.9-31smp.
I strongly recommend memtest86[1]. It runs from a floppy and is very good at
picking up memory errors. After that check out your hard disk with whatever
program your HDD manufacturer provides. But memory is the most likely.
Just in case, open the case and check for dust buildup and loose cables.
[1] http://www.memtest86.com/
HTH,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> There are 10 kinds of people in the world, those that can do binary
> arithmetic and those that can't.
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)