Thread: Any real known bugs about wrong selects?
Hi, we are currently using another database product but besides some licensing issues we are finding more and more problems with the database. We are evaluating PostgreSQL and it looks quite handy. Interesting features paired with good performance and a lot of users seems to be a prove for the quality. I wonder if people encountered bugs like 'a select returns a wrong number of rows' or any other very serious bugs. We do not have problems with things like database crashes (because we already needed to check and fix such things with the other database product) or with slow execution time in some cases but we take it very serious if a bug results in -wrong- result sets because we are calculating bills and other things which is very sensible to wrong results from select statements. As PostgeSQL is not a commercial product i hope that we are getting real, more reliable answers about bugs than from the database producer whose product we are using since now. Regards David
Hello David, I was relay on postgresql for years and now got trouble like you are talking about, but i did not solve it yet to be sure that this in not a matter of my hands but a problem of PG. See [GENERAL] insertion with trigger failed unexpectedly Discussion. Many people trying to help me so if it is not a PG problem i could tell you that i'm using PG for 4 years at least in a some number of sites (low traffic huge bases, very high traffic sites, combined) and have had no problems. Regards, Anton Nikiforov DT> Hi, DT> we are currently using another database product but besides some DT> licensing issues we are finding more and more problems with the DT> database. We are evaluating PostgreSQL and it looks quite handy. DT> Interesting features paired with good performance and a lot of users DT> seems to be a prove for the quality. DT> I wonder if people encountered bugs like 'a select returns a wrong DT> number of rows' or any other very serious bugs. We do not have problems DT> with things like database crashes (because we already needed to check DT> and fix such things with the other database product) or with slow DT> execution time in some cases but we take it very serious if a bug DT> results in -wrong- result sets because we are calculating bills and DT> other things which is very sensible to wrong results from select DT> statements. DT> As PostgeSQL is not a commercial product i hope that we are getting DT> real, more reliable answers about bugs than from the database producer DT> whose product we are using since now. DT> Regards David DT> ---------------------------(end of broadcast)--------------------------- DT> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
--- David Teran <david.teran@cluster9.com> wrote: > Hi, > > we are currently using another database product but > besides some > licensing issues we are finding more and more > problems with the > database. We are evaluating PostgreSQL and it looks > quite handy. > Interesting features paired with good performance > and a lot of users > seems to be a prove for the quality. > > I wonder if people encountered bugs like 'a select > returns a wrong > number of rows' or any other very serious bugs. We > do not have problems > with things like database crashes (because we > already needed to check > and fix such things with the other database product) > or with slow > execution time in some cases but we take it very > serious if a bug > results in -wrong- result sets because we are > calculating bills and > other things which is very sensible to wrong results > from select > statements. > > As PostgeSQL is not a commercial product i hope that > we are getting > real, more reliable answers about bugs than from the > database producer > whose product we are using since now. You appear to be asking "Does it work?" ??? PostgreSQL has been used in many real business applications for a number of years, and in recent times, more and more large, mission critical systems. Check http://advocacy.postgresql.org for more on that. I have been reading the PostgreSQL mailing lists for several years now, and have seen many bug reports. Few of these turn out to be actual bugs, usually they are due to error or misunderstanding by the user, or else hardware failures. In those few cases where the bugs are genuine, there is usually a patch released within hours of the report. Try and match that anywhere else. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
> You appear to be asking "Does it work?" ??? > Yes ;-) > PostgreSQL has been used in many real business > applications for a number of years, and in recent > times, more and more large, mission critical systems. > Check http://advocacy.postgresql.org for more on that. > Checked that, sounds great. > I have been reading the PostgreSQL mailing lists for > several years now, and have seen many bug reports. > Few of these turn out to be actual bugs, usually they > are due to error or misunderstanding by the user, or > else hardware failures. In those few cases where the > bugs are genuine, there is usually a patch released > within hours of the report. Try and match that > anywhere else. > The real question was: are there open known bugs where a select statement does not return a correct result, meaning a wrong number of rows? Were there a lot of errors like this? We are asking this because this makes trouble with the database we are currently using. Of course we know that there is no guarantee that pgsql works 100% bugfree but we are only asking for user experience. regards David
> The real question was: are there open known bugs where a select > statement does not return a correct result, meaning a wrong number of > rows? Were there a lot of errors like this? > We are asking this because this makes trouble with the database we are > currently using. Of course we know that there is no guarantee that > pgsql works 100% bugfree but we are only asking for user experience. > I do not know of any bug such as the one that you are describing. We have customers doing 240,000 transactaions and hour with PostgreSQL and have no issues. Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
On Tuesday 13 January 2004 15:08, Jeff Eckermann wrote: > > I have been reading the PostgreSQL mailing lists for > several years now, and have seen many bug reports. > Few of these turn out to be actual bugs, usually they > are due to error or misunderstanding by the user, or > else hardware failures. In those few cases where the > bugs are genuine, there is usually a patch released > within hours of the report. Try and match that > anywhere else. And if you want read them too, the archive is publicly available at the following URL: http://www.postgresql.org/lists.html You can see into our kitchens before sitting down to your meal... Oh - another place to get a feel for what sort of bugs get found/fixed in a live release, have a look in the online docs at the release notes. The only bug that's bitten me was one where a backup/restore didn't set the search_path correctly. It meant I had to intervene in a restore - inconvenient, nothing more. I think the most serious bug of recent times is probably the one fixed in 7.3.4 - search for server startup/WAL. As I recall, if some boundary condition was met the server would refuse to start. I don't believe it caused any damage to data. PS - Jeff's right about the response time. For actual bugs, it's often breathtakingly fast to get a patch. -- Richard Huxton Archonet Ltd
On Tue, 13 Jan 2004, David Teran wrote: > I wonder if people encountered bugs like 'a select returns a wrong > number of rows' or any other very serious bugs. We do not have problems It's happened on rare occasion in the past in my recollection for things that are basically bugs. It generally gets resolved quickly and usually someone can suggest workaround SQL while waiting. Nominally speaking, some of the case folding issues with identifiers might be considered to be such a problem: Select * from FOO, "foo" meaning something different when two tables were created as "FOO" and "foo" from what the spec would want. This is currently considered a don't do it sort of situation. Umm, there are some things that aren't really done yet, for example IIRC upper()/lower() really only work on single byte encodings. There are probably other things of this sort that one might need to watch out for.
On Tue, 13 Jan 2004, Joshua D. Drake wrote: > > > The real question was: are there open known bugs where a select > > statement does not return a correct result, meaning a wrong number of > > rows? Were there a lot of errors like this? > > We are asking this because this makes trouble with the database we are > > currently using. Of course we know that there is no guarantee that > > pgsql works 100% bugfree but we are only asking for user experience. > > > I do not know of any bug such as the one that you are describing. We > have customers doing 240,000 transactaions > and hour with PostgreSQL and have no issues. IIRC Tom found a bug in the hash indexing that MAY have resulted in short selects in certain race conditions, but there was no test case to prove it, and the likelyhood of it happening was really really low. The last data loss bugs I know of were in the 7.2.x branch and have long since been stamped out.
David Teran wrote: > > The real question was: are there open known bugs where a select > statement does not return a correct result, meaning a wrong number of > rows? Were there a lot of errors like this? > We are asking this because this makes trouble with the database we are > currently using. Of course we know that there is no guarantee that pgsql > works 100% bugfree but we are only asking for user experience. An error of this nature in any database is a very serious problem and you should really take it up with the vendor. If you can reproduce it I am sure they would try and supply a patch as soon as feasibly possible. I have seen databases return the wrong number of rows to queries loads of times or at least that is what it appears to be. On further investigation these apparent bugs turn out to be user errors in complicated sql statements. To date I have never seen a database return the anything other than what I have asked it for and Postgres is in this list. h
On Tue, 13 Jan 2004, Harry Jackson wrote: > David Teran wrote: > > > > The real question was: are there open known bugs where a select > > statement does not return a correct result, meaning a wrong number of > > rows? Were there a lot of errors like this? > > We are asking this because this makes trouble with the database we are > > currently using. Of course we know that there is no guarantee that pgsql > > works 100% bugfree but we are only asking for user experience. > > An error of this nature in any database is a very serious problem and > you should really take it up with the vendor. If you can reproduce it I > am sure they would try and supply a patch as soon as feasibly possible. > > I have seen databases return the wrong number of rows to queries loads > of times or at least that is what it appears to be. On further > investigation these apparent bugs turn out to be user errors in > complicated sql statements. To date I have never seen a database return > the anything other than what I have asked it for and Postgres is in this > list. Just an FYI, MSSQL server, in an older flavor from several years ago, had a bug where a statement like: select * into newtable from oldtable would return the right number of rows, as would select * from oldtable order by somefield however, select * into newtable from oldtable order by somefield would, under heavy load, return fewer rows than it should. With no error. Seeing as how the third query is often viewed as a "poor man's cluster" and wrapped in a begin;end; as well as rename / drop table script, that's quite dangerous to your data. MS fixed that one pretty quick, even though they hemmed and hawwed about how it wasn't very common, etc... I've seen a few other isolated instances of this kind of thing happening to other people, but seeing as how I use postgresql, I've never seen it myself. :-)