Bug #35982 Falcon crashes on concurrent load data infile
| Submitted: | 11 Apr 2008 0:31 | Modified: | 30 Sep 2008 19:19 |
|---|---|---|---|
| Reporter: | Vladislav Vaintroub | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Falcon storage engine | Severity: | S1 (Critical) |
| Version: | mysql-6.0-falcon-team | OS: | Any |
| Assigned to: | Christopher Powers | CPU Architecture: | Any |
[11 Apr 2008 0:31]
Vladislav Vaintroub
[11 Apr 2008 14:13]
Kevin Lewis
Chris, This seems like it could be a widespread bug. Thes is an unwritten assumption that the 'leaving' record could be NULL is garbageCollect. So we should check that before locking syncPrior
[11 Apr 2008 17:41]
Christopher Powers
Table::garbageCollect() now checks for null record pointers before initializing the syncPrior object. http://lists.mysql.com/commits/45293 ChangeSet@1.2638, 2008-04-11 12:34:18-05:00, cpowers@xeno.mysql.com +1 -0 Bug#35322, "Falcon duplicate primary keys on updateable views" Table::checkUniqueRecordVersion() locks record version chain before scanning. Bug#35982, "Falcon crashes on concurrent load data infile" Table::garbageCollect() checks for null record pointers before passing to Sync constructor.
[14 Apr 2008 18:42]
Bugs System
Pushed into 6.0.5-alpha
[30 Sep 2008 19:19]
Jon Stephens
Documented in the 6.0.5 changelog as follows:
Concurrent LOAD DATA INFILE statements inserting data
into Falcon tables could crash the server.
Portions of this website are copyright © 2001, 2002 The PHP Group
Page generated in 0.040 sec. using MySQL 8.4.7-u6-cloud
Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the
respective copyright holders.
It is not reviewed in advance
by Oracle and does not necessarily represent the opinion of
Oracle or any other party.