Well it would be a good idea to check the row validity. If the row is
partially corrupted, I can get an error (which is quite good) but I can get
bad results without an error as well, which is really bad.
After Tom decoded which row yields the problem, I tried to select the data
from the corrupted row:
dwhdb=# select * from dwhdata_salemc.fct where time_id = 14 and company_id =
2 and customer_id = 578 and product_id = 1059 and flagsprod_id = 107 and
flagssale_id = 2 and account_id = 362 and accttime_id = 13 and
invcustomer_id = 578 and salesperson_id = 2 and vendor_id = 16;
time_id | company_id | customer_id | product_id | flagsprod_id |
flagssale_id | account_id | accttime_id | invcustomer_id | salesperson_id |
vendor_id | inv_cost_amt | inv_base_amt | inv_amt | inv_qty | inv_wght |
ret_cost_amt | ret_base_amt | ret_amt | ret_qty | ret_wght | unret_cost_amt
| unret_base_amt | unret_amt |
unret_qty | unret_wght | bonus_forecast | bonus_final |
stamp_code
---------+------------+-------------+------------+--------------+--------------+------------+-------------+----------------+----------------+-----------+--------------+--------------+---------+---------+----------+--------------+--------------+---------+---------+----------+----------------+-----------------------------------+-----------------------------------+-----------------------------------+------------+----------------+-------------+----------------------
14 | 2 | 578 | 1059 | 107 |
2 | 362 | 13 | 578 | 2 | 16 |
0.0000 | 0.0000 | 0.1400 | 3.00 | 0.000 | 0.0000 |
0.0000 | 0.0000 | 0.00 | 0.000 | 8.0000 |
000040008000000000004000800000000
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| 000040008000000000004000800000000 | 000040008000000000004000800000000 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0.000 | 0.0000 | 0.0000 | INV_ASAS_20060601
^^^^^^^^^^^^^^^^^^^
(1 row)
As you can see, the underlined data is bad, but I get no error report. There
should be all zeros in the number fields, and 'INV_ASAS_20060101' instead of
'INV_ASAS_20060601' in the stamp field. This all is caused by a single bit
being inverted. I can see it very dangerous.
Regards
Filip Hrbek
----- Original Message -----
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Alvaro Herrera" <[EMAIL PROTECTED]>
Cc: "Filip Hrbek" <[EMAIL PROTECTED]>; <pgsql-bugs@postgreSQL.org>
Sent: Wednesday, August 30, 2006 4:10 AM
Subject: Re: [BUGS] Partially corrupted table
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
The underlined word is a field length word that evidently should contain
8, but contains hex 8008. This causes the tuple-data decoder to step
way past the end of the tuple and off into never-never land.
Hmm, perhaps we could protect against "impossible" length words?
Perhaps. I'm hesitant to add additional tests into the inner loop of
heap_deform_tuple and friends though. It's not like it's going to do
anything to recover your data post-corruption :-(
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
