On Mon, 2005-11-14 at 17:20, Kevin Grittner wrote:
> A programmer ran a query to fix some data against two "identical"
> databases -- one on Linux and one on Windows. They are both 8.1.0,
> running on dual hyperthreaded Xeons, with data on RAID5. The Linux
> update went fine. The Windows attempt give this:
>
> dtr=> UPDATE
> dtr-> "DbTranRepository"
> dtr-> SET "userId" = UPPER("userId")
> dtr-> WHERE (
> dtr(> ("userId" <> UPPER("userId")) AND
> dtr(> ("timestampValue" BETWEEN '2005-10-28' AND '2005-11-15'));
> ERROR: could not read block 649847 of relation 1663/16385/16483:
> Invalid argument
When a block is unreadable, this means that the OS is experiencing a
read error from the hard drive.
This is not necessarily related to the OS you are running so much as the
hardware you are running on top of.
If you were running on top of a RAID 1+0 or RAID 5 array, such an error
would likely never have happened, since it would have been detected by
the controller, and either the bad block would be mapped out or the
drive would be kicked out of the array and you'd get a system alert
telling you you had a bad drive in your array.
All Databases expect to run on "perfect" hardware. If the hardware gets
a read error, the database is NOT going to know what to do to fix it.
So, right now, it's not Linux 1, Windows 0, it's The box you're running
Linux on 1, the box you're running Windows on 0.
You've got a drive with a bad block.
Are you running on quality hardware (ECC memory, Server class SCSI
drives, battery backed cache hardware RAID array, etc...) or just
whatever was laying about unused. If you're not running your database
on quality hardware, you can't expect reliable results from your
testing, because what you're going to see are the hardware issues
showing up, not the database issues.
That said. PostgreSQL has been running on unix or some flavor of it
since its inception. It's been running on Windows in native mode for
about a year now. I'd say Liunx is going to be a better choice for
production for a while.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
