[BUGS] Bug #422: testing the subject and header changes
test ([EMAIL PROTECTED]) reports a bug with a severity of 4 The lower the number the more severe it is. Short Description testing the subject and header changes Long Description testing Sample Code No file was uploaded with this report ---(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] timestamps cannot be created without time zones
> Rainer Mager ([EMAIL PROTECTED]) reports a bug with a severity of 2 > Creating a TABLE with a TIMESTAMP type seems to ignore the WITH TIME > ZONE option. That is, with or without the option the TIMESTAMP still > has a time zone. We feel that the SQL timestamp definition as regards with/without time zone is undesirable. Our timestamp type always stores the time in UTC and prints it out according to the local time zone. The fact that the type then comes out as 'timestamp with time zone' is disputed, but they are in fact one and the same type. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] Bug #423: unable to do selects on certain fields in large tables
dave miller ([EMAIL PROTECTED]) reports a bug with a severity of 1 The lower the number the more severe it is. Short Description unable to do selects on certain fields in large tables Long Description In a table of about 300 MG, I am unable browse or select the text field - xml (holding a large XML document ) of any record. We noticed the problem after deleting about 50,000 records from the 100,000+ record table. We can select any other field but the xml field, but not any whole record. Sample Code PostgreSQL said: ERROR: chunk 1 for toast value 1227454 appears multiple times No file was uploaded with this report ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[BUGS] Bug #424: JDBC driver security issue.
David Daney ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
JDBC driver security issue.
Long Description
The JDBC driver requires
permission java.lang.RuntimePermission "shutdownHooks";
in the policy file in order to function. However the driver does not protect the
shutdown hooks call in an AccessController.doPrivileged() call, so these permissions
must be granted to all code not just the postgres JDBC driver.
Sample Code
Here is a diff that fixes the problem.
*** ConnectionHook.java.origMon Mar 5 01:17:43 2001
--- ConnectionHook.java Thu Aug 23 16:51:49 2001
***
*** 1,6
--- 1,9
package org.postgresql.core;
import java.sql.SQLException;
+ import java.security.AccessController;
+ import java.security.PrivilegedAction;
+
import java.util.ArrayList;
import java.util.Iterator;
import org.postgresql.Connection;
***
*** 51,57
*/
private ConnectionHook() {
super();
! Runtime.getRuntime().addShutdownHook(new Thread(this));
}
/**
--- 54,65
*/
private ConnectionHook() {
super();
! AccessController.doPrivileged(new PrivilegedAction() {
! public Object run() {
! Runtime.getRuntime().addShutdownHook(new Thread(ConnectionHook.this));
! return null; // nothing to return
! }
!});
}
/**
No file was uploaded with this report
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] memory leak while using vaccum
Achim =?iso-8859-1?Q?Kr=FCmmel?= <[EMAIL PROTECTED]> writes: > when using "vacuum analyze " on very large tables (I have one > with about 30GB) the memory usage increases continues until no memory is > left and the kernel stops this process. I don't have 30Gb to spare, but I set up a table of the same schema with a couple hundred meg of toy data and vacuumed it. I didn't see any significant memory usage (about 8 meg max). If there is a lot of free space in your 30Gb table then it's possible that the problem is simply vacuum's data structures that keep track of free space. What exactly are you using as the process memory limit, and can you increase it? FWIW, the default vacuum method for 7.2 is designed to use a fixed amount of memory no matter how large the table. That won't help you much today, however. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Bug #425: Upper(), Lower() bug
[EMAIL PROTECTED] writes: > The functions Lower amd Upper doesn't work with cyrillic, but > works fine with latin (a-z A-Z). upper/lowercase conversions are driven by LOCALE setting, not by multibyte character set. As far as I can tell, you have not done anything to select a cyrillic locale. regards, tom lane ---(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
[BUGS] Bug #425: Upper(), Lower() bug
Dmitry Bezgodov ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description Upper(), Lower() bug Long Description The functions Lower amd Upper doesn't work with cyrillic, but works fine with latin (a-z A-Z). Tested on psql (PostgreSQL) 7.1.3 with PostgreSQL 7.1.3 on i686-pc-cygwin, compiled by GCC 2.95.3-5. System: MS Windows 98 2nd russian edition. I tryed work via PostgreSQL ODBC 7.01.00.06 in pgAdmin and Active Perl 5.6 DBD-ODBC - it was the same result. Regards, Dmitry Bezgodov Sample Code $psql --version psql (PostgreSQL) 7.1.3 contains readline, history, multibyte support Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group Portions Copyright (c) 1996 Regents of the University of California Read the file COPYRIGHT or use the command \copyright to see the usage and distribution terms. $createdb -T template1 -E LATIN5 -U DMYL -W ldb $psql -l List of databases Database | Owner | Encoding ---+---+-- ldb | DMYL | LATIN5 template0 | DMYL | LATIN5 template1 | DMYL | LATIN5 (3 rows) $psql -c 'SELECT VERSION()' ldb version -- PostgreSQL 7.1.3 on i686-pc-cygwin, compiled by GCC 2.95.3-5 (1 row) === Some code SET CLIENT_ENCODING TO 'WIN' -- WIN is shortcut of Windows 1251 codepage ( Windows Cyrillic ) CREATE TABLE mytable ( id int4 primary key, namevarchar(80) not null) INSERT INTO product VALUES( 1, 'Windows cp1251 encoding cyrillic text') SELECT name, Upper(name), Lower(name) from mytable -- Output of those fields are equal, Lower and Upper functions don't -- change a value of field 'name'. No file was uploaded with this report ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: [BUGS] timestamps cannot be created without time zones
Thanks for the info. I'm unsure on a few things, though. The Postgres docs mention the the precision/range of timestamp with and withount a timezone is different. Are you saying that, because they are, internally, the same the precision/range is also the same? Also, we have seen a bug regarding time stamps when they are set via JDBC. We thought that it might be a core Postgres bug but after playing with psql a bit I think it may be in the JDBC driver. What happens is that when a timestamp is written to the database, if the timestamp is earlier than 1901 (I don't know the exact cutoff date), the the time is munged at some point. Via psql I verified that this date is important: 1901-08-08 01:00:00 1902-08-08 01:00:00+09 Notice that the 1901 date looses the timezone. Via JDBC, these older date are not properly handled athe the +09 hours of the timezone are not properly accounted for. Specifically, if I insert (via JDBC) '1-Jan-1900 :00:00:00' and then select it back out I get '31-Dec-1900:15:00:00'. This is not a good thing. Should I enter a new bug? Thanks, --Rainer > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Eisentraut > Sent: Friday, August 24, 2001 12:15 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [BUGS] timestamps cannot be created without time zones > > > > Rainer Mager ([EMAIL PROTECTED]) reports a bug with a severity of 2 > > > Creating a TABLE with a TIMESTAMP type seems to ignore the WITH TIME > > ZONE option. That is, with or without the option the TIMESTAMP still > > has a time zone. > > We feel that the SQL timestamp definition as regards with/without time > zone is undesirable. Our timestamp type always stores the time in UTC and > prints it out according to the local time zone. The fact that the type > then comes out as 'timestamp with time zone' is disputed, but they are in > fact one and the same type. > > -- > Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [BUGS] timestamps cannot be created without time zones
"Rainer Mager" <[EMAIL PROTECTED]> writes: > The Postgres docs mention the the precision/range of timestamp with and > withount a timezone is different. Where are you reading that, exactly? Since there isn't any difference between "timestamp with and without a timezone", that can't possibly be what was meant --- so we need to fix/clarify the documentation. Please tell us where. > What happens is that when a timestamp is written to the database, if the > timestamp is earlier than 1901 (I don't know the exact cutoff date), the the > time is munged at some point. Timezone handling in PG is dependent on the underlying OS' timezone database, which doesn't go back further than 1901 in any Unix that I've heard of. You should realize of course that the very notion of timezone was only standardized in the 1800s, so attaching a timezone to dates much older than that would be a dubious practice anyway... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
