Skip site navigation (1) Skip section navigation (2)

Re: Partially corrupted table

From: "Filip Hrbek" <filip(dot)hrbek(at)plz(dot)comstar(dot)cz>
To: <pgsql-bugs(at)postgreSQL(dot)org>
Subject: Re: Partially corrupted table
Date: 2006-08-30 12:43:19
Message-ID: 005601c6cc31$df5596f0$1e03a8c0@fhrbek (view raw or flat)
Thread:
Lists: pgsql-bugs
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 


In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2006-08-30 15:25:11
Subject: Re: BUG #2598: Columns named R are not accessible - although R is not a keyword
Previous:From: Teodor SigaevDate: 2006-08-30 10:25:37
Subject: Re: BUG #2594: Gin Indexes cause server to crash on Windows

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group