Re: myisamchk --unpack bug in 3.23.42 - Martin MOKREJŠ - com.mysql.lists.bugs

24 messages in com.mysql.lists.bugsRe: myisamchk --unpack bug in 3.23.42

From	Sent On	Attachments
Martin MOKREJŠ	19 Nov 2001 03:13
Michael Widenius	19 Nov 2001 07:15
Michael Widenius	21 Nov 2001 14:48
Martin MOKREJŠ	22 Nov 2001 02:31
Martin MOKREJŠ	22 Nov 2001 04:17
Michael Widenius	22 Nov 2001 05:10
Michael Widenius	22 Nov 2001 10:21
Martin MOKREJŠ	08 Dec 2001 14:40
Martin MOKREJŠ	08 Dec 2001 16:08
Michael Widenius	08 Dec 2001 17:36
Martin MOKREJŠ	08 Dec 2001 18:40
Michael Widenius	09 Dec 2001 04:34
Michael Widenius	09 Dec 2001 05:03
Michael Widenius	09 Dec 2001 05:07
Martin MOKREJŠ	09 Dec 2001 08:31
Martin MOKREJŠ	09 Dec 2001 09:05
Martin MOKREJŠ	09 Dec 2001 09:15
Michael Widenius	10 Dec 2001 07:21
Michael Widenius	10 Dec 2001 07:31
Martin MOKREJŠ	10 Dec 2001 08:03
Martin MOKREJŠ	10 Dec 2001 14:55
Michael Widenius	10 Dec 2001 15:55
Martin MOKREJŠ	11 Dec 2001 02:56
Michael Widenius	11 Dec 2001 04:07

Subject:	Re: myisamchk --unpack bug in 3.23.42
From:	Martin MOKREJŠ (mmok...@natur.cuni.cz)
Date:	12/09/2001 09:15:38 AM
List:	com.mysql.lists.bugs

On Sun, 9 Dec 2001, Michael Widenius wrote:

Hi Michael,

Has this table been ok at some point after it was compressed ?

mmokrejs> So my previous e-mail (the looong-one) should answer you YES, it was
fine mmokrejs> and you are able to verify my statement just by comparing it with the
.MYD mmokrejs> which you got previously in the *_ok.tgz file (or just use the .MYI
file mmokrejs> from the *_ok.tgz archive with it).

See my answer to this email.

See my answer to that email: this table wasn't modified. It was only locked, if accessed, that's true. But surely not really modified. I'm talking abot Rsphaeroides.blast_self.data, to be clear.

myisamchk tells us about this table: (myisamchk -dv)

MyISAM file: blast_self_data Record format: Packed

Which means that MyISAM thinks this table is NOT compressed (based on the index file).

mmokrejs> OK, -dv option doesn't force myisamchk to read the status from .MYD,
but mmokrejs> from .MYI. I probably need explanation what myisamchk does and from
where mmokrejs> it reads status of tables and how is the behavior affected by
commandline mmokrejs> options.

Alls status information execept how (not if) the data file was compressed comes from the .MYI file.

The reason we save how the table was compressed in the data file is to make it possible to reconstruct the .MYI file from an empty .MYI table.

Well, now I'm really starting to understand more. ;))

mmokrejs> I'm uploading for you mmokrejs> Burkholderia_pseudomallei_K96243_known3d_data_game.tgz , which
contains my mmokrejs> current status as at the end of my long e-mail. But, you should be
able to mmokrejs> reproduce it with the data you already have.

I don't think I need this as I already know the cause of your problems.

Yes, and I'll as an exercise use truncate table and then repair table to get it back to life. ;)

mmokrejs> And the hanging repair table prcess which I did not manage to kill (or mmokrejs> better to say get rid of it in SHOW PROCESSLIST output probably killed
m mmokrejs> mysqld right now, The load was >3 whiel I was gzipping the data for
you:

<cut>

mmokrejs> 0x807b83f handle_segfault__Fi + 383 mmokrejs> 0x812bdfa pthread_sighandler + 154 mmokrejs> 0x8153ba7 memcpy + 39 mmokrejs> 0x80fe5ed _mi_rec_unpack + 617 mmokrejs> 0x810c6de sort_get_next_record + 2758 mmokrejs> 0x8109d85 mi_repair + 1393 mmokrejs> 0x80c5308 repair__9ha_myisamP3THDR17st_mi_check_paramb + 624 mmokrejs> 0x80c500e repair__9ha_myisamP3THDP15st_ha_check_opt + 286 mmokrejs> 0x80cbea0
mysql_admin_table__FP3THDP13st_table_listP15st_ha_check_optPCc13thr_lock_typebT5UiPM7handlerFP7handlerP3THDP15st_ha_check_opt_i
+ 1432 mmokrejs> 0x80cec3e mysql_repair_table__FP3THDP13st_table_listP15st_ha_check_opt
+ 70 mmokrejs> 0x8082d01 mysql_execute_command__Fv + 4133 mmokrejs> 0x8085dc6 mysql_parse__FP3THDPcUi + 210 mmokrejs> 0x80813ed do_command__FP3THD + 1261 mmokrejs> 0x80808ec handle_one_connection__FPv + 548

I am quite sure that the above happened because you was running myisamchk and repair table on the same table at the same time.

(In MySQL 4.0 we have already added some safety checks in my_rec_unpack() to make it less likely to crash in the case of a badly formated compressed table).

But I think it's enough just to start the repair on the .MYD (compressed) table + .MYI stating Packed, as is in the *game.tgz file. You will have to wait a while, but I crashed it in the morning twice, and I think second time even without the need to run myisamchk/pack while mysqld was trying to repaiir it in memory. And the timestamps do not change, as far as I have the impression. I can repeat this for you, if you wish, but I think it's really enough just to run repair table and wait.

I have to leave now, no more experiments. Have a nice day!