Correction:
dtr=> select count(*) from "DbTranRepository"
dtr-> WHERE (
dtr(> ("userId" <> UPPER("userId")) AND
dtr(> ("timestampValue" BETWEEN '2005-10-28' AND '2005-11-15'));
count
--------
611255
(1 row)
I'm becoming more convinced that this happens as the UPDATE
runs into rows inserted by itself.
To respond to a concern expressed earllier -- all of our database
servers, including these two, use ECC memory.
-Kevin
>>> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> >>>
The table has about 23.3 million rows, of which about 200,000 will
be affected by this update. Run time is about an hour. During the
first run, the table was the target of about 45,000 inserts. This rerun
was done as the only task. A third run (also by itself) gave this:
ERROR: could not read block 1482762 of relation 1663/16385/16483:
Invalid argument
So the block number is increasing each time. I'm inclined to think
that this is the result of the scan passing over rows added by itself.
-Kevin
>>> Qingqing Zhou <zhouqq@cs.toronto.edu> >>>
> I reran the query. Same error, same relation, different block.
>
> 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 1118215 of relation 1663/16385/16483:
> Invalid argument
>
So this is a big query? Somebody reported this error when IO is
intensive.
To conclude the reports we have received:
(1) If IO is intensive (no matter you have anti-virus software or not),
you may encounter "invalud argument" error;
(2) In some cases, anti-virus software could cause "invalid argument"
error;
(3) You may encounter "permission denied" problem (no matter you have
anti-virus software or not) in some unknown condition;
Unfortunately we haven't found out the cause of this problem ... I am
thinking an urgent need is let PG print the GetLastError() for Windows
version as well.
Regards,
Qingqing
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
