Alex,
a possible temporary workaround you can try: use
LOCK TABLES intraday_PAR WRITE;
in your deleting transaction. It will lock updaters out
of your table while the delete batch is running.
There probably is a bug in hangdling of concurrent deletes
and updates in Innobase. I will try to repeat your problem on our
Sun and fix it. You Alex are probably my best stress tester of the
database :).
Regards,
Heikki
>Bonjour,
>
>
I have a table created with :>>CREATE TABLE intraday_PAR (
> symbole char(20) NOT NULL default '',
> date datetime NOT NULL default '0000-00-00 00:00:00',
^^^^
>Don't use reserved words for column names.
> first double(17,5) NOT NULL default '0.00000',
> high double(17,5) NOT NULL default '0.00000',
> low double(17,5) NOT NULL default '0.00000',
> last double(17,5) NOT NULL default '0.00000',
> volume int(11) NOT NULL default '0',> PRIMARY KEY (symbole,date),
> KEY idx_symbole (symbole),> KEY idx_date (date)>) TYPE=Innobase;>
> There are about 400.000 rows in it :>
>mysql> select count(*) from intraday_PAR;>+----------+>| count(*) |
>+----------+>| 379568 |>+----------+>1 row in set (0.86 sec)>
> If I try to do a delete based on "date" (for which there is an
> index), it is really really long :>
>| 5 | root | localhost | cotations | Query | 255 | updating |
>delete from intraday_PAR where date<'2001-04-03 00:00:00'>
> Before mysqld crashes :>
>mysql> delete from intraday_PAR where date<'2001-04-03 00:00:00';
>ERROR 2013: Lost connection to MySQL server during query>>
> And from the error log :>
>/usr/local/mysql/libexec/mysqld: ready for connections>mysqld got signal 11;
>The manual section 'Debugging a MySQL server' tells you how to use a
>stack trace and/or the core file to produce a readable backtrace that may
>help in finding out why mysqld died.>010403 12:32:19 mysqld restarted
>Innobase: Database was not shut down normally.
>Innobase: Starting recovery from log files...
>Innobase: Starting log scan based on checkpoint at
>Innobase: log sequence number 0 487424247
>Innobase: Doing recovery: scanned up to log sequence number 0 487489536
>Innobase: Doing recovery: scanned up to log sequence number 0 487555072
>Innobase: Doing recovery: scanned up to log sequence number 0 487600404
>Innobase: 1 uncommitted transaction(s) which must be rolled back
>Innobase: Starting rollback of uncommitted transactions
>Innobase: Rolling back trx no 4045747
>Innobase: Rolling back of trx no 4045747 completed
>Innobase: Rollback of uncommitted transactions completed
>Innobase: Starting an apply batch of log records to the database...
>Innobase: Apply batch completed>Innobase: Started
>/usr/local/mysql/libexec/mysqld: ready for connections>>
> Regards,
> Alex.>
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
