diff options
| author | Annamalai Gurusami <annamalai.gurusami@oracle.com> | 2013-03-27 11:11:38 +0530 |
|---|---|---|
| committer | Annamalai Gurusami <annamalai.gurusami@oracle.com> | 2013-03-27 11:11:38 +0530 |
| commit | ff20c67fe4c6182bbee359d9bdaece09199670c5 (patch) | |
| tree | dd50b70c2487b593d2030bc6928ba451f471d0ab /storage/innobase/include | |
| parent | cf23bb763b8adecfce2bd3276d5697c8a1e5022e (diff) | |
| download | mariadb-git-ff20c67fe4c6182bbee359d9bdaece09199670c5.tar.gz | |
Bug #16244691 SERVER GONE AWAY ERROR OCCURS DEPENDING ON THE NUMBER OF
TABLE/KEY RELATIONS
Problem:
When there are many tables, linked together through the foreign key
constraints, then loading one table will recursively open other tables. This
can sometimes lead to thread stack overflow. In such situations the server
will exit.
I see the stack overflow problem when the thread_stack is 196608 (the default
value for 32-bit systems). I don't see the problem when the thread_stack is
set to 262144 (the default value for 64-bit systems).
Solution:
Currently, in InnoDB, there is a macro DICT_FK_MAX_RECURSIVE_LOAD which defines
the maximum number of tables that will be loaded recursively because of foreign
key relations. This is currently set to 250. We can reduce this number to 33
(anything more than 33 does not solve the problem for the default value). We
can keep it small enough so that thread stack overflow does not happen for the
default values. Reducing the DICT_FK_MAX_RECURSIVE_LOAD will not affect the
functionality of InnoDB. The tables will eventually be loaded.
rb#2058 approved by Marko
Diffstat (limited to 'storage/innobase/include')
| -rw-r--r-- | storage/innobase/include/dict0mem.h | 25 |
1 files changed, 21 insertions, 4 deletions
diff --git a/storage/innobase/include/dict0mem.h b/storage/innobase/include/dict0mem.h index 8a55fef7f73..21ae248ce9e 100644 --- a/storage/innobase/include/dict0mem.h +++ b/storage/innobase/include/dict0mem.h @@ -1,7 +1,24 @@ -/****************************************************** -Data dictionary memory object creation +/***************************************************************************** + +Copyright (c) 1996, 2013, Oracle and/or its affiliates. All Rights Reserved. + +This program is free software; you can redistribute it and/or modify it under +the terms of the GNU General Public License as published by the Free Software +Foundation; version 2 of the License. + +This program is distributed in the hope that it will be useful, but WITHOUT +ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS +FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. -(c) 1996 Innobase Oy +You should have received a copy of the GNU General Public License along with +this program; if not, write to the Free Software Foundation, Inc., +51 Franklin Street, Suite 500, Boston, MA 02110-1335 USA + +*****************************************************************************/ + +/**************************************************//** +@file include/dict0mem.h +Data dictionary memory object creation Created 1/8/1996 Heikki Tuuri *******************************************************/ @@ -300,7 +317,7 @@ This could result in rescursive calls and out of stack error eventually. DICT_FK_MAX_RECURSIVE_LOAD defines the maximum number of recursive loads, when exceeded, the child table will not be loaded. It will be loaded when the foreign constraint check needs to be run. */ -#define DICT_FK_MAX_RECURSIVE_LOAD 250 +#define DICT_FK_MAX_RECURSIVE_LOAD 33 /** Similarly, when tables are chained together with foreign key constraints with on cascading delete/update clause, delete from parent table could |