Any real known bugs about wrong selects?

[David Teran]

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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postg resql.org

[Anton.Nikiforov]

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 ma*******@postg resql.org
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

[Jeff Eckermann]

--- David Teran <da*********@cl uster9.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 misunderstandin g 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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

[David Teran]

> 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 misunderstandin g 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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Joshua D. Drake]

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.
[phone] - jd@commandpromp t.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

[Harry Jackson]

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

[Richard Huxton]

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 misunderstandin g 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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

[Stephan Szabo]

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.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

[scott.marlowe]

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.
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

[scott.marlowe]

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. :-)
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html