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


> Alvaro Herrera <alvherre@commandprompt.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