Comment 6 for bug 978036

Bart -

Yes, good catch, thank you. These offsets work are for databases that
do not use compression and use the default 16K page size.

In other cases they will need to be calculated manually for space = 0,
page = 7, 4 bytes at page offset 52 (DICT_HDR_STATS) and 8 bytes at
page offset 256 (DICT_HDR_XTRADB_MARK).

2012 m. balandis 25 d. 14:33, Bart Verwilst <email address hidden> rašė:
> Hi,
>
> I guess the 114778 offset of ibdata1 in the comment above is strictly
> for our database, and cannot be applied with the same offset on other
> ibdata files for other users that might stumble onto this bugreport
> right? Just to make sure that nobody totally corrupts their data by
> copy-pasting from comment #4 :)
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/978036
>
> Title:
>  Percona server crashes on ALTER TABLE on temporary table
>
> Status in Percona Server with XtraDB:
>  In Progress
> Status in Percona Server 5.1 series:
>  Triaged
> Status in Percona Server 5.5 series:
>  In Progress
>
> Bug description:
>  We have a 3.2TB big production server running SLES 11.1 and Mysql
>  Server 5.1.54.
>
>  I created a backup with xtrabackup ( and cp, rsync, ... on other
>  occasions ), and used this data to setup a new server on CentOS 6.2
>  with Percona server 5.5.21 ( and 5.1.61 later on to make sure it
>  wasn't only related to 5.5, which it isnt, crashes on PS 5.1 as well.
>  ).
>
>  Setting up a slave to the 'old' server from the CentOS server works
>  like a charm, 25000 seconds worth of transactions completed just fine,
>  and the PS 5.5 instance caught up with the master.
>
>  Then i wanted to create a temporary table, fill it with some data, and then needed to add a primary key to it. It crashed.
>  I have consistently been able to reproduce it on this data by doing:
>
>  mysql> use test
>  Reading table information for completion of table and column names
>  You can turn off this feature to get a quicker startup with -A
>
>  Database changed
>  mysql> create temporary table t1 (id int);
>  Query OK, 0 rows affected (1.97 sec)
>
>  mysql> alter table t1 engine=myisam;
>  ERROR 2013 (HY000): Lost connection to MySQL server during query
>
>
>  Tried both with engine=myisam and innodb.
>
>  I've resolved the stacktrace to this:
>
>      0x3188a0f4a0 _end + -2020000832
>      0x9149db fil_space_is_corrupt + 391995
>      0x8fdefa fil_space_is_corrupt + 299098
>      0x86c48a _ZN21ha_innobase_add_indexD0Ev + 427834
>      0x81d241 _ZN21ha_innobase_add_indexD0Ev + 103665
>      0x822310 _ZN21ha_innobase_add_indexD0Ev + 124352
>      0x823e51 _ZN21ha_innobase_add_indexD0Ev + 131329
>      0x9117f8 fil_space_is_corrupt + 379224
>      0x911f76 fil_space_is_corrupt + 381142
>      0x816cbd _ZN21ha_innobase_add_indexD0Ev + 77677
>      0x817ceb _ZN21ha_innobase_add_indexD0Ev + 81819
>      0x8e9e92 fil_space_is_corrupt + 217074
>      0x834bc6 _ZN21ha_innobase_add_indexD0Ev + 200310
>      0x7f6b7b innobase_get_trx + 5419
>      0x5910aa _Z16check_valid_pathPKcm + 5322
>      0x51654a unireg_abort + 2858
>      0x50fa79 _start + 41
>
>  Full mysqld.err attached ( disregard the beginning of the file, that
>  was before my backup was restored there ;) ).
>
>  Using a clean /var/lib/mysql doesn't trigger the crash, so it must be
>  some kind of corruption in the live data..
>
>  Good luck!
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/percona-server/+bug/978036/+subscriptions

--
Laurynas