Re: tablecrash on MySQL-Max-4.0.16

Hi

> If a table were corrupted, a query would not run.
> UPDATE would simply and immediately return the error to the client.
That didn't happend. The update did not return immediately but was only 
stalling.

Anyway, we replaced the mysqlserver with your binary rpm's. That fixed our 
problem. We have now tested for several days and we have not experienced even 
a single crash after the upgrade.

The conclusion then is that recompiling your SRPMs on a rh90 box will NOT 
build stable mysql binaries.

Thanks for you insights

Best regards,
Vidar

On Wednesday 10 December 2003 19:18, Sinisa Milivojevic wrote:
> Vidar writes:
> > 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]'
> >
> > All queries have status "Locked". And only queries concerning ezsession
> > is running on the server when I do a "show full processlist;"
>
> If a table were corrupted, a query would not run.
>
> UPDATE would simply and immediately return the error to the client.
>
> The aboev could be simply long running command or some problem with
> file system or external locking is used. Or binary has problems.
>
>
> --
>
> Sincerely,

-- 
vidar



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