Mauricio,
hmm... I wonder if MySQLCC makes mysqld to cache the whole result set of the
query. How big is the result set? Could mysqld run out of memory because of
it?
Konstantin fixed some prepared statement bug to 4.1.6. It might be that bug.
I do not know if MySQLCC or its successor, MySQL Administrator uses prepared
statements. You can download and test MySQL Administrator on this.
Regards,
Heikki
----- Alkuperäinen viesti -----
Lähettäjä: "Mauricio Pellegrini" <hrrg-inf@stripped>
Vastaanottaja: "Heikki Tuuri" <Heikki.Tuuri@stripped>
Kopio: "MySql List" <mysql@stripped>
Lähetetty: Saturday, September 25, 2004 2:12 AM
Aihe: Re: SV: Mysql goes down when executing query
> Heikki,
>
> I was collecting information about the incident and preparing a detailed
> bug report, when decided to repeat the whole process from within
> the mysql client, (I mean the original text mode client that comes with
> the server installation)
>
> I was surprised to see that problem DOES NOT occur from within that
> client.
>
> Immediatly I ran the query from the Control Center ( v.0.9.4-beta)
> and the problem happened again.
>
> So, this obviously related to the use of the MySql Control Center
> v.0.9.4-beta and therefore there's no need to file such bug report.
>
> Am I right?
>
> I didn't know that a Client program could cause mysql to restart in that
> way.
>
> by the way as I've seen that the control center is no longer under
> development which program would you suggest to replace it.( assuming the
> same capabilities, of course )
>
>
> Thank you very much
> Mauricio
>
> P.S. Im using SuSE v.8.2
>
>
>
> On Thu, 2004-09-16 at 08:11, Heikki Tuuri wrote:
> > Mauricio,
> >
> > looks like a bug in the MySQL parser.
> >
> > Please file a DETAILED bug report at bugs.mysql.com
> >
> > Make sure you describe precisely how we can REPEAT the problem here.
> >
> > Thank you,
> >
> > Heikki
> >
> > ----- Alkuperäinen viesti -----
> > Lähettäjä: "Mauricio Pellegrini" <hrrg-inf@stripped>
> > Vastaanottaja: "Heikki Tuuri" <Heikki.Tuuri@stripped>
> > Kopio: "MySql List" <mysql@stripped>
> > Lähetetty: Thursday, September 16, 2004 7:25 PM
> > Aihe: Re: SV: Mysql goes down when executing query
> >
> >
> > > Heikki,
> > >
> > > I've tried a different query this time but always using the
> > > "INTO OUTFILE" syntax.
> > >
> > > Mysqld went down and up again.
> > >
> > > This is the resolved stack dump
> > >
> > > 0x808a183 handle_segfault + 423
> > > 0x82d3cb8 pthread_sighandler + 184
> > > 0x80ae46f yyparse__FPv + 59623
> > > 0x809d894 mysql_parse__FP3THDPcUi + 68
> > > 0x8097e4f dispatch_command__F19enum_server_commandP3THDPcUi + 1643
> > > 0x80977d8 do_command__FP3THD + 188
> > > 0x8096f17 handle_one_connection + 615
> > > 0x82d146c pthread_start_thread + 220
> > > 0x82fa9fa thread_start + 4
> > >
> > > Thanks
> > > Mauricio
> > >
> > >
> > > On Thu, 2004-09-16 at 00:52, Heikki Tuuri wrote:
> > > > Mauricio,
> > > >
> > > > please resolve the stack dump below.
> > > >
> > > > Best regards,
> > > >
> > > > Heikki Tuuri
> > > > Innobase Oy
> > > > Foreign keys, transactions, and row level locking for MySQL
> > > > InnoDB Hot Backup - a hot backup tool for InnoDB which also backs up
> > MyISAM
> > > > tables
> > > > http://www.innodb.com/order.php
> > > >
> > > > Order MySQL technical support from https://order.mysql.com/
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Mauricio Pellegrini" <hrrg-inf@stripped>
> > > > Newsgroups: mailing.database.myodbc
> > > > Sent: Wednesday, September 15, 2004 3:46 PM
> > > > Subject: Re: SV: Mysql goes down when executing query
> > > >
> > > >
> > > > > Thanks, but already have innodb_buffer_pool_size=160M
> > > > > and I've raised innodb_additional_mem_pool_size from 2M to 10M
> > > > >
> > > > > And the problem remains the same.
> > > > >
> > > > > Any sugestions?
> > > > >
> > > > > Thanks
> > > > > Mauricio
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, 2004-09-14 at 18:05, Nickolai Nielsen wrote:
> > > > > > Hi
> > > > > >
> > > > > > Try setting these variables in you conf:
> > > > > > set-variable = innodb_buffer_pool_size=128M
> > > > > > set-variable = innodb_additional_mem_pool_size=10M
> > > > > >
> > > > > > you have to experiment with the size as it depends on how
> much
ram
> > you
> > > > > > hardware has.
> > > > > >
> > > > > > Nickolai Nielsen
> > > > > >
> > > > > > -----Oprindelig meddelelse-----
> > > > > > Fra: hrrg-inf@stripped [mailto:hrrg-inf@stripped]
> > > > > > Sendt: 14. september 2004 22:39
> > > > > > Til: MySql List
> > > > > > Emne: Mysql goes down when executing query
> > > > > >
> > > > > >
> > > > > > Hi, Sorry to disturb but Mysql 4.1.4 gamma goes down when
executing
> > this
> > > > > > query.
> > > > > >
> > > > > > I've tryed the same query without the coalesce function and
> the
> > problem
> > > > > > persists.
> > > > > >
> > > > > > select
> > > > > > coalesce(viehc,0),
> > > > > > coalesce(vieapellido,0),
> > > > > > coalesce(vienombres,0),
> > > > > > coalesce(viedoc,0),
> > > > > > coalesce(numero,0),
> > > > > > coalesce(apellido,0),
> > > > > > coalesce(nombres,0),
> > > > > > coalesce(f_nacimiento,0),
> > > > > > coalesce(sexo,0),
> > > > > > coalesce(doc_numero,0)
> > > > > > from zzg_int.compara
> > > > > > into outfile "/tmp/compa.txt"
> > > > > > fields terminated by ','
> > > > > > lines terminated by '\r\n';
> > > > > >
> > > > > > This is what the error log shows.
> > > > > >
> > > > > > Version: '4.1.4-gamma-standard-log' socket:
> '/tmp/mysql.sock'
> > port:
> > > > > > 3306 Official MySQL-standard binary
> > > > > > mysqld got signal 11;
> > > > > > This could be because you hit a bug. It is also possible
> that
this
> > > > > > binary
> > > > > > or one of the libraries it was linked against is corrupt,
improperly
> > > > > > built,
> > > > > > or misconfigured. This error can also be caused by
malfunctioning
> > > > > > hardware.
> > > > > > We will try our best to scrape up some info that will
> hopefully
help
> > > > > > diagnose
> > > > > > the problem, but since we have already crashed, something
> is
> > definitely
> > > > > > wrong
> > > > > > and this may fail.
> > > > > >
> > > > > > key_buffer_size=16777216
> > > > > > read_buffer_size=258048
> > > > > > max_used_connections=13
> > > > > > max_connections=100
> > > > > > threads_connected=10
> > > > > > It is possible that mysqld could use up to
> > > > > > key_buffer_size + (read_buffer_size +
> > sort_buffer_size)*max_connections
> > > > > > = 92783 K
> > > > > > bytes of memory
> > > > > > Hope that's ok; if not, decrease some variables in the
> equation.
> > > > > >
> > > > > > thd=0x4b22efb8
> > > > > > Attempting backtrace. You can use the following information
> to
find
> > out
> > > > > > where mysqld died. If you see no messages after this,
> something
went
> > > > > > terribly wrong...
> > > > > > Cannot determine thread, fp=0xbfddeb68, backtrace may not
> be
> > correct.
> > > > > > Stack range sanity check OK, backtrace follows:
> > > > > > 0x808a183
> > > > > > 0x82d3cb8
> > > > > > 0x80ae46f
> > > > > > 0x809d894
> > > > > > 0x8097e4f
> > > > > > 0x80977d8
> > > > > > 0x8096f17
> > > > > > 0x82d146c
> > > > > > 0x82fa9fa
> > > > > > New value of fp=(nil) failed sanity check, terminating
> stack
trace!
> > > > > > Please read
> http://www.mysql.com/doc/en/Using_stack_trace.html
and
> > > > > > follow instructions on how to resolve the stack trace.
> Resolved
> > > > > > stack trace is much more helpful in diagnosing the problem,
> so
> > please do
> > > > > > resolve it
> > > > > > Trying to get some variables.
> > > > > > Some pointers may be invalid and cause the dump to abort...
> > > > > > thd->query at 0x86da708 = EXPLAIN select
> > > > > >
> > > >
> > coalesce(viehc,0),coalesce(vieapellido,0),coalesce(vienombres,0),coalesc
e(vi
> > > > > > edoc,0),coalesce(numero,0),
> > > > > >
> > > >
> >
coalesce(apellido,0),coalesce(nombres,0),coalesce(f_nacimiento,0),coalesce(s
> > > > > > exo,0),coalesce(doc_numero,0)
> > > > > > from hrrg_int.compara
> > > > > > into outfile "/tmp/compa.txt" fields terminated by ','
> lines
> > terminated
> > > > > > by '\r\n'
> > > > > > thd->thread_id=632
> > > > > > The manual page at
> http://www.mysql.com/doc/en/Crashing.html
> > contains
> > > > > > information that should help you find out what is causing
> the
crash.
> > > > > >
> > > > > > Number of processes running now: 0
> > > > > > 040914 13:15:00 mysqld restarted
> > > > > > 040914 13:15:00 [ERROR] Warning: Asked for 196608 thread
> stack,
but
> > got
> > > > > > 126976
> > > > > > 040914 13:15:00 InnoDB: Database was not shut down
> normally!
> > > > > > InnoDB: Starting crash recovery.
> > > > > > InnoDB: Reading tablespace information from the .ibd
> files...
> > > > > > InnoDB: Restoring possible half-written data pages from the
> > doublewrite
> > > > > > InnoDB: buffer...
> > > > > > 040914 13:15:00 InnoDB: Starting log scan based on
> checkpoint
at
> > > > > > InnoDB: log sequence number 0 281648573.
> > > > > > InnoDB: Doing recovery: scanned up to log sequence number 0
> > 281648583
> > > > > > InnoDB: Last MySQL binlog file position 0 79779, file name
> > > > > > ./hrrgp01-bin.000005
> > > > > > 040914 13:15:00 InnoDB: Flushing modified pages from the
> buffer
> > pool...
> > > > > > 040914 13:15:00 InnoDB: Started; log sequence number 0
281648583
> > > > > > /usr/local/mysql/bin/mysqld: ready for connections.
> > > > > > Version: '4.1.4-gamma-standard-log' socket:
> '/tmp/mysql.sock'
> > port:
> > > > > > 3306 Official MySQL-standard binary
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > MySQL General Mailing List
> > > > > > For list archives: http://lists.mysql.com/mysql
> > > > > > To unsubscribe:
> > http://lists.mysql.com/mysql?unsub=1
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > MySQL General Mailing List
> > > > > For list archives: http://lists.mysql.com/mysql
> > > > > To unsubscribe:
> > > > http://lists.mysql.com/mysql?unsub=1
> > > > >
> > > >
> > >
> >
>
