What is happening to Informix?

I'm sorry, I just have to vent a bit. For the second time in 6 months, we have just experienced Informix crashing (assert failures) due to iniput of a syntactically and semantically correct SQL statement. The first time, we were on 11.5 (FC7, I think), tech support said the problem would be fixed in the next release. Two days ago (a few hours after we upgraded to 11.7FC5) another crash due to inability of Informix to handle proper SQL (this one had some LEFT OUTER JOINs). This time we got a "W" release, and the problem is solved... BUT, it is simply astounding to me, and unfathomable, that a mature database engine could be crashed by the input of proper SQL. I am left defensless in responding to a new hotshot develooper who has nothing but contempt for Informix ("a toy database") because his SQL has crashed the system twice in 6 months. In the past 10 years, Informix has been like a rock. I can't even recall one crash. But, recently... what's happening? There, I feel better now. DG

If you feel better, than it's good. For the readers, this will probably be a politically incorrect post... On Thu, Aug 23, 2012 at 8:45 PM, <davidegrove@gmail.com> wrote: > I'm sorry, I just have to vent a bit. > > For the second time in 6 months, we have just experienced Informix > crashing (assert failures) due to iniput of a syntactically and > semantically correct SQL statement. The first time, we were on 11.5 (FC7, > I think), tech support said the problem would be fixed in the next release. > Two days ago (a few hours after we upgraded to 11.7FC5) another crash due > to inability of Informix to handle proper SQL (this one had some LEFT OUTER > JOINs). This time we got a "W" release, and the problem is solved... > Any crash, and I really mean any crash is a reason to be upset. But you somehow seem to imply that it would be ok if the statement had some kind of problem. And this really surprises me. A database engine has a lot of things to do... It has to parse the statement, check the parameters (for prepared statements), check the security, calculate the query plan and execute it. All this steps are done by code, and any code may contain bugs. >From my point of view, parsing the code and the parameters is the easier part. Calculate the query plan and execute it is a much more complex task and as such much more error prone. Should it crash? Of course not, but it's a much more probable phase than the ones before. > > BUT, it is simply astounding to me, and unfathomable, that a mature > database engine could be crashed by the input of proper SQL. > A crash before is much more strange. And I'm sure it happened before also. > > I am left defensless in responding to a new hotshot develooper who has > nothing but contempt for Informix ("a toy database") because his SQL has > crashed the system twice in 6 months. In the past 10 years, Informix has > been like a rock. I can't even recall one crash. But, recently... what's > happening? > You could suggest that developer to google for other database bug list... He will surely get a different perspective. Once he does that, ask him to open a problem at their support and compare the time it takes, and the answers he gets. From your said history you hit two different bugs that IBM was able to identify and fix. I spent half to two thirds of my customer facing time (most of my working time) in an environment with at least 4 different types of databases. Interestingly enough apparently only Informix has open problems with support... why? Not because it crashes (I could get you uptimes of really interesting environments), but simply because they constantly change the use and test new features and we hit issues and doubts. And specially because they almost gave up opening tickets in other vendors because of the terrible support they get (and because the Informix DBA team is much more demanding than the others (a workaround is treated as just that and not a definitive solution) > > There, I feel better now. > Me too... but really, the only purposes of this post are: 1- Defend that a crash is a crash whenever it happens. And the SQL "quality" should have nothing to do with it. A crash should never happen, period 2- There is nothing wrong "now". Try to browse through the list of fixed bugs in every Informix fixpack. All of them will show possible crashes, wrong results, bad performance etc. The same applies to all databases. It's just the way software is and software makers try to fight it. Ask your developer if he would consider more normal that one of his programs crashed while parsing user input, than if it crashed, core dumps or whatever after the user presses "SAVE". Naturally the quality perception derives from your experience. Two bugs in 6 months after 10 years of stability can of course change the perception. But it does not show a trend or a change. 3- Your two situations were checked and worked on by tech support. They worked with the data generated by the engine while crashing and the internal database. Answers were found and fixes were produced or were already available. If Informix had another (less efficient) architecture, with less shared resources it would be easier to keep away from crashes when something goes wrong. In fact with some configurations we can prevent it from crashing sometimes. But a crash is typically generated by an assert fail. An assert failure is a generic term that means that a condition test (integrity) has failed and it may be unsafe to proceed. It shows that the code has robustness built in. It does a lot of integrity checking while it's working to prevent worse problems Now, of course a crash is a nasty thing and nobody likes them. We surely don't. Hopefully you'll continue working with more stability. By the way, this crash happened in tests or production? Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...