[BUGS] List of bugs
Hi, My name is Ilir Gashi and I am a final year student at City University, London, UK. I am doing the final year project, titled "Failure diversity between PostgreSQL and Interbase", which is part of an ongoing reserach at the University the aim of which is to test if there is a gain in reliability, performance and fault-tolerance from employing multiple diverse SQL servers. For my part of the project a list of known bugs which cause a failure of PostgreSQL will be run on the Interbase server to test whether a coincident failure also occurs in this server. And vice versa, a list of known bugs of Interbase will be run on PostgreSQL so that coincidence of failures can be tested. The results of these tests will be collected and summarized so that a valid conclusion can be drawn on whether there is a gain in reliability from employing PostgreSQL and Interbase together in a fault-tolerant SQL server. In order to do the project I need a list of bugs for one of the versions of PostgreSQL. I already obtained the list of known bugs for the Interbase 6.0 from the Firebird website. My question is do you maintain a list of known bugs with the detailed descriptions of the causes of the bug. I would be grateful if you could send me the list of known bugs for versions 7.2 and 7.3. Sorry for the long email, and thank you in advance, Ilir Gashi __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] List of bugs
Hi, Thanks for the quick response. I was looking through the archives of pgsql-bugs and I saw that the number of bugs reported is 830 something. Does that mean that these bugs are all for the latest version or for all the versions. If it is for all versions than in some cases it wasn't specified as to for which version was the bug found for, so do I just assume it is for the latest one or contact you to find out. One last question. Since my project has a time limit for completion I need to to reproduce only about 100 bugs during my tests. Do you think there are that many known bugs so far for the latest version. This would help me to know, since I need to know which version of postgres to install and add to the existing test harness which alredy has Interbase 6, MsSQL and Oracle. Thanks in advance, Ilir --- Tom Lane <[EMAIL PROTECTED]> wrote: > ILIR GASHI <[EMAIL PROTECTED]> writes: > > My question is do you maintain a list of known > bugs > > with the detailed descriptions of the causes of > the > > bug. > > We do not. You could grovel through the archives of > pgsql-bugs > though... > > regards, tom lane __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] List of Bugs
Hi, Thanks for the quick response. I was looking through the archives of pgsql-bugs and I saw that the number of bugs reported is 830 something. Does that mean that these bugs are all for the latest version or for all the versions. If it is for all versions than in some cases it wasn't specified as to for which version was the bug found for, so do I just assume it is for the latest one or contact you to find out. One last question. Since my project has a time limit for completion I need to to reproduce only about 100 bugs during my tests. Do you think there are that many known bugs so far for the latest version. This would help me to know, since I need to know which version of postgres to install and add to the existing test harness which alredy has Interbase 6, MsSQL and Oracle. Thanks in advance, Ilir --- Tom Lane <[EMAIL PROTECTED]> wrote: > ILIR GASHI <[EMAIL PROTECTED]> writes: > > My question is do you maintain a list of known > bugs > > with the detailed descriptions of the causes of > the > > bug. > > We do not. You could grovel through the archives of > pgsql-bugs > though... > > regards, tom lane __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] Possible bug?
Hello,
I saw this 'bug' reported in the Firebird SourceForge website for the
Firebird 1.0 server. They confirmed it as a bug! I tried it in PostgreSQL
7.2 (I know its an old release but I do not have a newer version installed,
and in any case I am only using the server for reserach purposes).
PostgreSQL returns no rows for either of the queries. Of course this is the
case since the attributes F1 and F2 of Table T1 are of type Char whereas
the select query is making the test with an integer value. Is this the
intended behaviour?
Firebird returns 0 rows for the first query and 1 row (values 3,3) for the
second query. I also tried it in Oracle 8.0.5 which returns 1 row for each
of the two queries. Therefore I have different results being returned from
all three servers.
Reproducible script:
CREATE TABLE T1 (F1 CHAR(4), F2 CHAR(4));
CREATE INDEX T1_F1 ON T1 (F1);
INSERT INTO T1 (F1, F2) VALUES ('001', '001');
INSERT INTO T1 (F1, F2) VALUES ('002', '002');
INSERT INTO T1 (F1, F2) VALUES ('003', '003');
INSERT INTO T1 (F1, F2) VALUES ('004', '004');
SELECT * FROM T1 WHERE F1 = 3;
F1 F2
SELECT * FROM T1 WHERE F2 = 3;
F1 F2
Best regards,
Ilir
--
Ilir Gashi
PhD Student
Centre for Software Reliability
City University
Northampton Square, London EC1V 0HB
Tel: +44 20 7040 0273
Fax: +44 20 7040 8585
email: [EMAIL PROTECTED]
website: http://www.csr.city.ac.uk/csr_city/staff/gashi/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[BUGS] No rows returned from the SQL query (possible bug)
Hello,
I saw this 'bug' reported in the Firebird SourceForge website for the
Firebird 1.0 server. They confirmed it as a bug! I tried it in PostgreSQL
7.2 (I know its an old release but I do not have a newer version installed,
and in any case I am only using the server for reserach purposes).
PostgreSQL returns no rows for either of the queries. Of course this is the
case since the attributes F1 and F2 of Table T1 are of type Char whereas
the select query is making the test with an integer value. Is this the
intended behaviour?
Firebird returns 0 rows for the first query and 1 row (values 3,3) for the
second query. I also tried it in Oracle 8.0.5 which returns 1 row for each
of the two queries. Therefore I have different results being returned from
all three servers.
Reproducible script:
CREATE TABLE T1 (F1 CHAR(4), F2 CHAR(4));
CREATE INDEX T1_F1 ON T1 (F1);
INSERT INTO T1 (F1, F2) VALUES ('001', '001');
INSERT INTO T1 (F1, F2) VALUES ('002', '002');
INSERT INTO T1 (F1, F2) VALUES ('003', '003');
INSERT INTO T1 (F1, F2) VALUES ('004', '004');
SELECT * FROM T1 WHERE F1 = 3;
F1 F2
SELECT * FROM T1 WHERE F2 = 3;
F1 F2
Best regards,
Ilir
--
Ilir Gashi
PhD Student
Centre for Software Reliability
City University
Northampton Square, London, UK EC1V 0HB
email: [EMAIL PROTECTED]
website: http://www.csr.city.ac.uk/csr_city/staff/gashi/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Possible bug?
On Jul 1 2004, Stephan Szabo wrote:
Technically speaking, I believe the queries are simply invalid without the
presence of casts from the spec's standpoint.
Theoretically, I'd either expect both to give 0 rows (convert 3 into a
string and compare) or both to give 1 row (convert '003' to an integer and
compare) if it didn't error.
What does Oracle do if you insert a value like 'XXX' into the column?
Below is the behaviour of Oracle 8.0.5 for the value 'XXX'
CREATE TABLE T1 (F1 CHAR(4), F2 CHAR(4));
CREATE INDEX T1_F1 ON T1 (F1);
INSERT INTO T1 (F1, F2) VALUES ('001', '001');
INSERT INTO T1 (F1, F2) VALUES ('002', '002');
INSERT INTO T1 (F1, F2) VALUES ('XXX', '003');
INSERT INTO T1 (F1, F2) VALUES ('004', '004');
SELECT * FROM T1 WHERE F1 = 3;
ORA-01722: invalid number
SELECT * FROM T1 WHERE F2 = 3;
F1 F2
XXX 003
1 row selected.
So, yes Oracle is doing a char to integer implicit conversion and
performing an integer with integer comparison.
Thanks for the quick response.
(BTW I appologise for my last report being posted twice. I was not a member
of PGSQL-bugs list when I posted the first one, and since it was taking a
while for it to be approved, I decied to join the list and then post it
again.)
Best regards,
Ilir
--
Ilir Gashi
PhD Student
Centre for Software Reliability
City University
Northampton Square, London EC1V 0HB
email: [EMAIL PROTECTED]
website: http://www.csr.city.ac.uk/csr_city/staff/gashi/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] timestamp arithmetic (a possible bug?)
Hi,
I saw this behaviour in PostgreSQL 7.2. (Once again, I know this is an old
release but I do not have a newer version installed, and I am only using
the server for research purposes). If you execute the following statement
SELECT (CAST('01.01.2004 10:01:00' AS TIMESTAMP) - CAST('01.01.2004
10:00:00' AS TIMESTAMP)) + CAST('01.01.2004 10:00:00' AS TIMESTAMP);
The result returned is:
?column?
-
2004-01-01 00:01:00
(1 row)
I was expecting: 2004-01-01 10:01:00.
Tried it on Oracle 8.0.5:
SELECT TO_DATE('01.01.2004 10:01:00', 'DD.MM. HH:MI:SS') -
TO_DATE('01.01.2004 10:00:00', 'DD.MM. HH:MI:SS') + TO_DATE('01.01.2004
10:00:00', 'DD.MM. HH:MI:SS') FROM DUAL;
---
2004-01-01 10:01:00
(1 row selected)
And MSSQL 7:
SELECT (CAST('01.01.2004 10:01:00' AS DATETIME) - CAST('01.01.2004
10:00:00' AS DATETIME) + CAST('01.01.2004 10:00:00' AS DATETIME));
---
2004-01-01 10:01:00.000
(1 row(s) affected)
Is this a bug? Same thing happens if I use TimestampTZ rather than
Timestamp.
Best regards,
Ilir
Ilir Gashi
PhD Student
Centre for Software Reliability
City University
Northampton Square, London EC1V 0HB
email: [EMAIL PROTECTED]
website: http://www.csr.city.ac.uk/csr_city/staff/gashi/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] Grant Update (Possible bug)?
Hi, This is a another bug reported for the Firebird 1.0 server. I subsequently ran it in PostgreSQL 7.2, Oracle 8.0.5 anf MSSQL 7. Reproducible script: Connect as pgsql: CREATE TABLE TEST(ID INTEGER,NAME VARCHAR(50)); INSERT INTO TEST (ID) VALUES (1); GRANT UPDATE ON TEST TO TESTUSER; Connect as TestUser; UPDATE TEST SET NAME='TEST' WHERE ID=1; ERROR: test: Permission denied. UPDATE TEST SET NAME='TEST'; Executes successfully. So the user can update the whole table but not specific columns. Is this a bug or as specified (I read briefly the Reference Guide and I didn't see this highlited anywhere, but I may have missed it.). Firebird and MSSQL have the same behaviour as PostgreSQL (Firebird have acknowledged this as a bug, I haven't checked on MSSQL website yet.) In Oracle 8.0.5 both updates execute sucessfully. Best regards, Ilir ________ Ilir Gashi PhD Student Centre for Software Reliability City University Northampton Square, London EC1V 0HB email: [EMAIL PROTECTED] website: http://www.csr.city.ac.uk/csr_city/staff/gashi/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] timestamp arithmetic (a possible bug?)
On Jul 2 2004, Achilleus Mantzios wrote:
SELECT '01.01.2004 10:00:00'::timestamp + ('01.01.2004
10:01:00'::timestamp - '01.01.2004 10:00:00'::timestamp)::interval;
?column?
-
2004-01-01 10:01:00
(1 row)
works fine in my 7.4.2
Yes. I've just tried it in PostgreSQL 7.2 and it works fine there as well.
On Jul 2 2004, Theodore Petrosky wrote:
Interesting
If I reverse the order it works...
agencysacks=# SELECT CAST('01.01.2004 10:00:00' AS
TIMESTAMP) + (CAST('01.01.2004 10:01:00' AS TIMESTAMP)
- CAST('01.01.2004 10:00:00' AS TIMESTAMP)) as answer;
answer
-
2004-01-01 10:01:00
(1 row)
Yes. The above works for me as well in 7.2.
However your original...
agencysacks=# SELECT (CAST('01.01.2004 10:01:00' AS
TIMESTAMP) - CAST('01.01.2004 10:00:00' AS TIMESTAMP))
+ CAST('01.01.2004 10:00:00' AS TIMESTAMP);
ERROR: operator does not exist: interval + timestamp
without time zone
HINT: No operator matches the given name and argument
type(s). You may need to add explicit type casts.
agencysacks=# select version();
version
-
PostgreSQL 7.4.2 on powerpc-apple-darwin7.2.0,
compiled by GCC gcc (GCC) 3.3 20030304 (Apple
Computer, Inc. build 1495)
(1 row)
Looks like postgresql demands the order to be
timestamp +- interval.
Ted
I am not getting the error above. I get the incorrect result as reported in
my original report. Does this mean that this was a buggy behaviour in 7.2
and then was changed in the latter releases to give the error message that
7.4.2 is giving?
Thanks for the quick responses.
Best regards,
Ilir
Ilir Gashi
PhD Student
Centre for Software Reliability
City University
Northampton Square, London EC1V 0HB
email: [EMAIL PROTECTED]
website: http://www.csr.city.ac.uk/csr_city/staff/gashi/
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [BUGS] Grant Update (Possible bug)?
On Jul 2 2004, Tom Lane wrote: Ilir Gashi <[EMAIL PROTECTED]> writes: > This is a another bug reported for the Firebird 1.0 server. I > subsequently ran it in PostgreSQL 7.2, Oracle 8.0.5 anf MSSQL 7. > Reproducible script: > Connect as pgsql: > CREATE TABLE TEST(ID INTEGER,NAME VARCHAR(50)); > INSERT INTO TEST (ID) VALUES (1); > GRANT UPDATE ON TEST TO TESTUSER; > Connect as TestUser; > UPDATE TEST SET NAME='TEST' WHERE ID=1; > ERROR: test: Permission denied. > UPDATE TEST SET NAME='TEST'; > Executes successfully. This is not a bug. That UPDATE requires SELECT permission because it makes use of the ID field in the where clause. If you grant someone UPDATE but not SELECT, presumably you want them to be able to insert data but not learn anything about what is in the table. If we allowed such commands then something like UPDATE TEST SET NAME = NAME WHERE ID = 1 could be used to determine whether the table contains a row with ID=1 (by inspecting the reported row count). So it would be a security flaw. The SQL specification also requires this behavior. In SQL92 the Access Rules for say 1) The applicable privileges shall include SELECT for T if CR is contained in any of: a) a immediately contained in a or an ; or b) a immediately contained in an . > So the user can update the whole table but not specific columns. Is > this a bug or as specified (I read briefly the Reference Guide and I > didn't see this highlited anywhere, but I may have missed it.). > Firebird and MSSQL have the same behaviour as PostgreSQL (Firebird have > acknowledged this as a bug, I haven't checked on MSSQL website yet.) It's not a bug. Please withdraw the complaint against Firebird. > In Oracle 8.0.5 both updates execute sucessfully. Oracle is a very poor reference for SQL-spec-compliant behavior :-( regards, tom lane Thanks for the quick reply. I also suspected that it was not a bug, but was confused by The Firebird bug-tracker at SourceForge who had marked it as an 'Initial bug', and became even more confused from the behaviour of Oracle. Thanks for the clarification. Best regards, Ilir Ilir Gashi PhD Student Centre for Software Reliability City University Northampton Square, London EC1V 0HB email: [EMAIL PROTECTED] website: http://www.csr.city.ac.uk/csr_city/staff/gashi/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
