Re: Partially corrupted table

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" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "Filip Hrbek" <filip(dot)hrbek(at)plz(dot)comstar(dot)cz>; <pgsql-bugs(at)postgreSQL(dot)org>
Sent: Wednesday, August 30, 2006 4:10 AM
Subject: Re: [BUGS] Partially corrupted table

> Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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