Re: tablecrash on MySQL-Max-4.0.16

Hi

Thank you for your reply

> Where exactly on our ftp site did you upload the above process list ??
support.mysql.com/pub/mysql/secret/

> Can you just send the relevant snippet form it ??
96325   db32vl     localhost       db32vl     Query   34      Locked  UPDATE 
ezsession\n                    SET expiration_time='1071019479', 
data='[SNIP]'\n                    WHERE session_key='[SNIP]'

> We can not deduce based on the above where to look at all in order to
> find a cause of the problem.
> Also, what does it mean "table locks" ?? All MyISAM tables are locked
> with our queries.
All queries have status "Locked". And only queries concerning ezsession is 
running on the server when I do a "show full processlist;"

> Also, with 4.0.15 and up, all corruption reports so far, were traced
> back to hardware problems or to bad built binary.
> It is also unclear from your report whether you use our binary or not.
I said "The server is not installed with your precompiled binaries". What I 
was trying to say was that we do NOT use your binary. 

> This does not mean that the above is not a bug,
Well, I cannot think of any valid reason why mysql would lock all queries on 
this table, do you ? If you don't either, I will try you binaries instead.

>Only that this is not a fully repeatable test case which will enable
>us to corrupt table in each of it's runs.
I have no problem with understanding that you are unable to reproduce this. 
But I don't think a bug in my application could cause this mysql behaviour? 
So it is either a mysql bug or (more probably) a bad build binary ?

Again, thank you for your time.

Best regards,
Vidar


On Wednesday 10 December 2003 16:54, you wrote:
> Vidar writes:
> > Hi
> >
> > system : rh9
> > mysql :
> > MySQL-devel-4.0.16-0
> > MySQL-shared-4.0.16-0
> > MySQL-Max-4.0.16-0
> > MySQL-client-4.0.16-0
> > MySQL-server-4.0.16-0
> >
> > We have a table
> >
> > > desc ezsession;
> >
> > +-----------------+------------------+------+-----+---------+-------+
> >
> > | Field           | Type             | Null | Key | Default | Extra |
> >
> > +-----------------+------------------+------+-----+---------+-------+
> >
> > | session_key     | varchar(32)      |      | PRI |         |       |
> > | expiration_time | int(11) unsigned |      | MUL | 0       |       |
> > | data            | text             |      |     |         |       |
> > | cache_mask_1    | int(11)          |      |     | 0       |       |
> >
> > +-----------------+------------------+------+-----+---------+-------+
> >
> > This table is very often read/written to (only plain select, insert and
> > update queries, no joins). But sometimes it crashes. I have uploaded
> > tablecrash_max4016_full_processlist.tar.gz to your ftp account
> >
> > The table locks, so a restart of mysql and a "repair table ezsession;" is
> > needed in order to make the table work again.
>
> [skip]
>
> > PS
> > This is definitively  NOT a "disk full" problem
> >
> > --
> > Vidar Langseid
>
> HI!
>
> Where exactly on our ftp site did you upload the above process list ??
>
> Can you just send the relevant snippet form it ??
>
> We can not deduce based on the above where to look at all in order to
> find a cause of the problem.
>
> Also, what does it mean "table locks" ?? All MyISAM tables are locked
> with our queries.
>
> Also, with 4.0.15 and up, all corruption reports so far, were traced
> back to hardware problems or to bad built binary.
>
> It is also unclear from your report whether you use our binary or not.
>
> This does not mean that the above is not a bug,
>
> Only that this is not a fully repeatable test case which will enable
> us to corrupt table in each of it's runs.
>
> --
>
> Sincerely,

-- 
vidar



-- 
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe:    http://lists.mysql.com/[email protected]