[BUGS] JDBC-Driver produces wrong output.
Jan Thomae ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
JDBC-Driver produces wrong output.
Long Description
Hi,
I recently downloaded the last snapshot of PostgreSQL and also the newest JDBC-Driver
for it. I played a bit around with it and it seems to produce some really weird output
on datetimes and timestamps. I added a table "test" into the database, containing two
columns "test1" and "test2". "test1" is a timestamp, "test2" a datetime. Then I
entered the following date into each of the columns: 15.10.1978 20:47:56 CET. After
this I ran a small test program (see the attached source code). This produced the
following output:
|1981-11-15 20:00:56.0|1981-11-15 20:00:56.0
As you can see, the dates are different from what I entered into the database. This
error did not occur using the 6.4 PostgreSQL and belonging driver. Do I do something
wrong ?
Sample Code
Hashtable defaultProperties = new Hashtable();
defaultProperties.put(JDBCResource.HOSTNAME, "frodo");
defaultProperties.put(JDBCResource.PORT, "5432");
defaultProperties.put(JDBCResource.USERNAME, "jan");
defaultProperties.put(JDBCResource.PASSWORD, "");
defaultProperties.put(JDBCResource.DATABASE, "testdb");
Class.forName("org.postgresql.Driver");
Connection connection = DriverManager.getConnection(...)
Statement statement = connection.createStatement();
ResultSet rs = statement.executeQuery("SELECT * FROM test");
while (rs.next()) {
int cols = rs.getMetaData().getColumnCount();
for (int i=1; i<=cols; i++) {
System.out.print("|" + rs.getObject(i));
}
System.out.println("");
}
rs.close();
No file was uploaded with this report
[BUGS] My Bug report: JDBC-Driver produces wrong output.
Hi,
I had a look over the JDBC-Driver and was able to remove the bug. It seems,
that the formatting of the timestamp caused the malfunction. I'd like to send
you my modifications, since you might be interested in them:
File: ResultSet.java
Directory: src/interfaces/jdbc/org/postgresql/jdbc2
public Timestamp getTimestamp(int columnIndex) throws SQLException
{
String s = getString(columnIndex);
if(s==null)
return null;
// This works, but it's commented out because Michael Stephenson's
// solution is better still:
// SimpleDateFormat df = new SimpleDateFormat("-MM-dd HH:mm:ss");
// Modification by Jan Thomae
String sub = s.substring(s.length() - 3, s.length()-2);
if (sub.equals("+") || sub.equals("-")) {
s = s.substring(0, s.length()-3) + "GMT"+ s.substring(s.length()-3,
s.length())+":00";
}
// ---
// Michael Stephenson's solution:
SimpleDateFormat df = null;
// Modification by Jan Thomae
if (s.length()>27) {
df = new SimpleDateFormat("-MM-dd HH:mm:ssz");
} else
// ---
if (s.length()>21 && s.indexOf('.') != -1) {
df = new SimpleDateFormat("-MM-dd HH:mm:ss.SSzzz");
} else if (s.length()>19 && s.indexOf('.') == -1) {
df = new SimpleDateFormat("-MM-dd HH:MM:sszzz");
} else if (s.length()>19 && s.indexOf('.') != -1) {
df = new SimpleDateFormat("-MM-dd HH:MM:ss.SS");
} else if (s.length()>10 && s.length()<=18) {
df = new SimpleDateFormat("-MM-dd HH:MM:ss");
} else {
df = new SimpleDateFormat("-MM-dd");
}
try {
return new Timestamp(df.parse(s).getTime());
} catch(ParseException e) {
throw new PSQLException("postgresql.res.badtimestamp",new
Integer(e.getErrorOffset()),s);
}
}
Best regards,
Jan Thomae
--
Jan Thomae [EMAIL PROTECTED]
SMB GmbH http://www.smb-tec.com
[BUGS] LIKE(~~) OR regular pattern(~) deliver incomplete output
ernst reeh ([EMAIL PROTECTED]) reports a bug with a severity of 1 The lower the number the more severe it is. Short Description LIKE(~~) OR regular pattern(~) deliver incomplete output Long Description I work with POSTGRES version 6.4, so maybe the bug is already fixed. Please tell me if it's so. A search with LIKE(~~) or with regular patterns (~) won't give you all matching rows. If the first missing letter is a 'y' or a 'z', you won't get this row. (for example: you're searching for 'duftrei%'. You won't find 'duftreiz' or anything starting with 'duftreiz'. The same with 'duftrey'.) I really hope, this bug is already fixed. Bye Ernst Sample Code select * from flexwort; flexseq flex 1duftreiz 2duftreize (2 rows) select * from flexwort where flex ~~ 'duftrei%'; (0 rows) select * from flexwort where flex ~ '^duftrei.*'; (0 rows) select * from flexwort where flex ~~ 'duftre%'; flexseq flex 1duftreiz 2duftreize (2 rows) No file was uploaded with this report
[BUGS] version info to bug#94 (LIKE(~~) ...)
ernst reeh ([EMAIL PROTECTED]) reports a bug with a severity of 4 The lower the number the more severe it is. Short Description version info to bug#94 (LIKE(~~) ...) Long Description Sorry, i didn't give you the complete version info for my bug-report: PostgreSQL 6.4.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.6 Bye Ernst Sample Code No file was uploaded with this report
[BUGS] Bug#94 is related to compiler-version
ernst.reeh ([EMAIL PROTECTED]) reports a bug with a severity of 4 The lower the number the more severe it is. Short Description Bug#94 is related to compiler-version Long Description Sorry again, The bug didn't appear on another machine with the following version-info: PostgreSQL 6.4.2 on i686-pc-linux-gnu, compiled by gcc 2.95. (1 row) The 'wrong' compiler-version: -- PostgreSQL 6.4.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.6 So, its not a POSTGRES-Bug, it's a mess with different SUSE-, kernel-, Compiler-Versions. Bye Ernst Sample Code No file was uploaded with this report
Re: [BUGS] RPM install weirdness & BugreportPage Bug
Thomas Linden wrote: > I suggest a little bit more investigation and testing before publishing > rpm packages, a rpm package must be installable unless it cannot find a > required package. if this is the case, then this package must be You must put all the RPM's on the same command line invocation, or it won't work. There are circular dependencies in the old packaging, which cannot be rid of unless you upgrade all at once. Although, you may still get problems with the postgresql-data package -- like Thomas said, you may be better off dumping your data then uninstalling the old RPM's, and then installing the new. Are you running RedHat 6.x? RedHat 6.0 shipped PostgreSQL 6.4.2, RH 6.1 shipped 6.5.2, and 6.2 shipped 6.5.3. RedHat 7 shipped 7.0.2. RedHat 5.2 was the last RedHat release that shipped 6.3.2. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[BUGS] Bug in Time/Date routines
Hi Folks !
I just found a bug in the postgresql time/date routines.
Try the following in the psql shell :
select ('10-01-2000'::date + ('1 month')::timespan)::date;
The result is going to be
10-31-2000
But it should be
11-01-2000
If you take any other month than October, it is working fine. So 09-01-2000 + 1 month
=> 10-01-2000.
I've tested this with postgresql 6.5.3 as well as 7.0.2
Thanks for the good work
Moritz
P.S. what about a way to cancel a query that is waiting for a locked table / row ?
Re: [BUGS] Bug#94 is related to compiler-version
[EMAIL PROTECTED] writes: > So, its not a POSTGRES-Bug, it's a mess with different SUSE-, kernel-, >Compiler-Versions. More likely, it's related to what LOCALE you are using. There are known problems with LIKE optimization in non-ASCII locales, particularly in 6.4.*. Try updating to 7.0.* regards, tom lane
Re: [BUGS] Bug in Time/Date routines
Moritz Gmelin <[EMAIL PROTECTED]> writes:
> If you take any other month than October, it is working fine. So
> 09-01-2000 + 1 month => 10-01-2000.
Hmm, I was expecting to find that fixed in current sources, but it's
still broken:
regression=# select ('10-01-2000'::timestamp + ('1 month')::timespan);
?column?
2000-10-31 23:00:00-05
(1 row)
Thomas, isn't the addition of '1 month' done symbolically in a struct tm?
I suspect you may have forgotten to set tm_isdst = -1 before invoking
mktime(), causing it to interpret the time of day on the target date
as the same DST or not-DST case that applied on the initial date.
Seems to me that both times should be taken as "local time", so you
should force mktime() to recompute whether DST is in effect or not.
OTOH, it's much less clear whether that's a good idea when the timespan
is expressed in hours... maybe do this only if the timespan had a
nonzero "months" component? (Really, timespans should account for
months, days, and hours separately --- it's false that 1 day == 24 hours
-- so IMHO a reasonable implementation would reset isdst if either the
months or days component was nonzero. I don't have time to fix that for
7.1, however.)
> P.S. what about a way to cancel a query that is waiting for a locked table / row ?
That works in 7.0.*, no? Sure looks like it works to me:
play=> begin;
BEGIN
play=> lock table int4_tbl;
-- type control-C
Cancel request sent
ERROR: Query cancel requested while waiting lock
play=>
regards, tom lane
Re: [BUGS] Bug in Time/Date routines
> > If you take any other month than October, it is working fine. So
> > 09-01-2000 + 1 month => 10-01-2000.
> regression=# select ('10-01-2000'::timestamp + ('1 month')::timespan);
> ?column?
>
> 2000-10-31 23:00:00-05
> (1 row)
> Thomas, isn't the addition of '1 month' done symbolically in a struct tm?
> I suspect you may have forgotten to set tm_isdst = -1 before invoking
> mktime(), causing it to interpret the time of day on the target date
> as the same DST or not-DST case that applied on the initial date.
> Seems to me that both times should be taken as "local time", so you
> should force mktime() to recompute whether DST is in effect or not.
That particular operation needs mktime() called twice in some cases :(
Once for the input timestamp and once for the intermediate result. I'm
testing a fix now which gives the right result for this particular case.
- Tom
[BUGS] waiting for lock?
Hi, this evening I found a whole bunch of cron jobs hanging on a VACUUM of a database. I killed them off and retried manually: ulsec=> vacuum; NOTICE: Skipping "pg_type" --- only table owner can VACUUM it NOTICE: Skipping "pg_attribute" --- only table owner can VACUUM it NOTICE: Skipping "pg_proc" --- only table owner can VACUUM it NOTICE: Skipping "pg_class" --- only table owner can VACUUM it NOTICE: Skipping "pg_indexes" --- only table owner can VACUUM it NOTICE: Skipping "pg_group" --- only table owner can VACUUM it NOTICE: Skipping "pg_database" --- only table owner can VACUUM it NOTICE: Skipping "pg_attrdef" --- only table owner can VACUUM it NOTICE: Skipping "pg_relcheck" --- only table owner can VACUUM it NOTICE: Skipping "pg_trigger" --- only table owner can VACUUM it NOTICE: Skipping "pg_inherits" --- only table owner can VACUUM it NOTICE: Skipping "pg_index" --- only table owner can VACUUM it NOTICE: Skipping "pg_statistic" --- only table owner can VACUUM it NOTICE: Skipping "pg_operator" --- only table owner can VACUUM it NOTICE: Skipping "pg_opclass" --- only table owner can VACUUM it NOTICE: Skipping "pg_am" --- only table owner can VACUUM it NOTICE: Skipping "pg_amop" --- only table owner can VACUUM it NOTICE: Skipping "pg_amproc" --- only table owner can VACUUM it NOTICE: Skipping "pg_language" --- only table owner can VACUUM it NOTICE: Skipping "pg_aggregate" --- only table owner can VACUUM it NOTICE: Skipping "pg_ipl" --- only table owner can VACUUM it NOTICE: Skipping "pg_inheritproc" --- only table owner can VACUUM it NOTICE: Skipping "pg_rewrite" --- only table owner can VACUUM it NOTICE: Skipping "pg_listener" --- only table owner can VACUUM it NOTICE: Skipping "pg_description" --- only table owner can VACUUM it NOTICE: Skipping "pg_shadow" --- only table owner can VACUUM it NOTICE: Skipping "pg_user" --- only table owner can VACUUM it NOTICE: Skipping "pg_rules" --- only table owner can VACUUM it And there it hangs. strace reveals that the corresponding postgres process on the server hangs on: semop(10241, 0xbfffe924, 1 If you send psql a SIGINT, it returns with: NOTICE: Skipping "pg_rules" --- only table owner can VACUUM it Cancel request sent ERROR: Query cancel requested while waiting lock ulsec=> When this happened, no other clients were accessing the database. Restarting the server (postgresql 7.0.2) cured all. Anyone knows what's going on there? /Lennert
Re: [BUGS] RPM install weirdness & BugreportPage Bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yes, you are right, 6.3.2 was installed (which I never knew!) and contained that postgresql-clients package. After removing the old packages, everything worked very well. Thanks a lot for the help! regards, Thomas - -- => PGP key: http://daemon.de/key.txt => "Experience is what you got when => you did not get what you wanted." On Thu, 2 Nov 2000, Lamar Owen wrote: > Thomas Linden wrote: > > I suggest a little bit more investigation and testing before publishing > > rpm packages, a rpm package must be installable unless it cannot find a > > required package. if this is the case, then this package must be > > You must put all the RPM's on the same command line invocation, or it > won't work. There are circular dependencies in the old packaging, which > cannot be rid of unless you upgrade all at once. > > Although, you may still get problems with the postgresql-data package -- > like Thomas said, you may be better off dumping your data then > uninstalling the old RPM's, and then installing the new. > > Are you running RedHat 6.x? RedHat 6.0 shipped PostgreSQL 6.4.2, RH 6.1 > shipped 6.5.2, and 6.2 shipped 6.5.3. RedHat 7 shipped 7.0.2. RedHat > 5.2 was the last RedHat release that shipped 6.3.2. > -- > Lamar Owen > WGCR Internet Radio > 1 Peter 4:11 > -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6Ad9Vi8dcrd1c6OsRAit5AJ9pSGDWisc8vHgxXr6q98jgHqXnEwCgzqCX cqT7qZDtAcisz0+dDLiz75Q= =FOpR -END PGP SIGNATURE-
[BUGS] psql client segfault
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, me again :-) ok, after installing the rpm's everything was fine except connecting to the database using the supplied client program psql. It ended with a segmentation fault. So I thought it would be a good idea to try to install the software from source. The problem is, psql still exists with a segfault :-( After the segfault the terminal became unusable, that's why I think it could have to something with curses ...? My setup: RedHat 5.2 (yes) glibc 2.1.2-11 Kernel 2.2.12-20 ncurses 4.2-10 termcap 9.12.6-15 readline 2.2.1-1 I get the segfault both as postgres user or as any other user (including root). createdb/createuser works well, compilation of the sources too, no errors or warnings (well, some really unimportant unused defs...). I don't want to bother everybody on this list with huge attachments, so I put the coredump as well as the strace output on my webpage: http://www.0x49.org/~scip/psql-7.0.2-segfault.strace.tar.gz. Thanks in advance, Thomas - -- => PGP key: http://daemon.de/key.txt => "Experience is what you got when => you did not get what you wanted." -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6Afvqi8dcrd1c6OsRAiZXAKDvGp96fgctrY4Ec9x0QEujT4iTCgCgt1Qd CJFZlBWMTRdF2s7KBqMoJWk= =ZaSj -END PGP SIGNATURE-
Re: [BUGS] psql client segfault
A corefile is of no value to anyone running on a platform even slightly different from your own. Could you please compile psql with -g, reproduce the problem, and then send in a gdb backtrace from that core? Also, what exactly are you doing that provokes the coredump? FWIW, I have a RedHat 5.1 box on which I sometimes test postgres, so the mere fact that your system is old isn't the issue. regards, tom lane
Re: [BUGS] performace about your search engine
On Thu, 2 Nov 2000 [EMAIL PROTECTED] wrote: > P. Ashok Kumar ([EMAIL PROTECTED]) reports a bug with a severity of 2 > The lower the number the more severe it is. > > Short Description > performace about your search engine > > Long Description > You search engine takes long time to give results. Many times It's > session is timed out. we have new hardware on order to rectify this problem, assuming that I've been able to properly identify where the bottleneck is. After doing some research on the existing system, and spending some time talking with some of the FreeBSD SCSI developers, it turns out that the SCSI drives on the database server that is managing the search engine data are pretty much saturated. This is with the search engine data spread over 2 SCSI drives ... we've ordered in 2 9gig drives to spread the data over more, as well as have a 3rd drive that used to be in that machine that is off under RMA, giving us 5 spindles to spread the data load over ... we *hope* to have the 2 new drives installed late tomorrow, if all goes well and they get in *cross fingers*
