[BUGS] BUG #1477: DROP TABLE does not recover
The following bug has been logged online: Bug reference: 1477 Logged by: Marcel Claus Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: Windows 2003 Server / Windows XP Description:DROP TABLE does not recover Details: Hi, I have found the following problem and I can reproduce it any time using psql.exe or the C#-API-Calls. The problem: I create a table with a primary key, using for example the statement: create table test2 ( a varchar(10), b varchar(3), c numeric(8,4), constraint key_test2 primary key (a) ); When I now try to drop this table with DROP TABLE test2; the table will be droppped but I dont get an ackknowledge or some other response, so the calling program or method waits forever for an answer. In the filesystem the files of the table (the files with the numbers (OID) as names) still exist. They are not deleted. I think they should have been deleted too. It seems to be a problem with the index, because when I create the table without the index: create table test2 ( a varchar(10), b varchar(3), c numeric(8,4) ); the "DROP TABLE test2;" works fine. I also tried this one: create table test2 ( a varchar(10), b varchar(3), c numeric(8,4), constraint key_test2 primary key (a) ); alter table test2 drop constraint key_test2; This also leeds to a waiting command prompt and the calling application doesnt recover. When I shut down the calling application (with the Task-Manager) after waiting for 5 seconds the table is dropped. Thank you for your held. Regards, Marcel Claus ---(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] PreparedStatement setObject
Setting java.lang.String values with the setObject method in version 8 of the pgsql-jdbc driver (postgresql-8.0-310.jdbc3.jar) does not work as with version 7 (pg74.215.jdbc3.jar) of the driver. Example: Create a prepared statement with sql "select localtimestamp - time ?". Call setObject(1, java.lang.String) with the String value "00:00:00" for instance. In version 7 this gets executed as "select localtimestamp - time '00:00:00'", while version 8 try to execute it as "select localtimestamp - time 00:00:00", which of cause fails since the quotes are missing. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] Bug in ALTER LANGUAGE ... RENAME TO ...;
RenameLanguage procedure in src/backend/commands/proclang.c open and update pg_catalog.pg_shadow table instead pg_catalog.pg_language. -- Sergey N. Yatskevich <[EMAIL PROTECTED]> diff -Naur postgresql-8.0.0/src/backend/commands/proclang.c postgresql-8.0.0.new/src/backend/commands/proclang.c --- postgresql-8.0.0/src/backend/commands/proclang.c 2005-01-01 00:59:41 +0300 +++ postgresql-8.0.0.new/src/backend/commands/proclang.c 2005-02-11 20:36:47 +0300 @@ -246,7 +246,7 @@ HeapTuple tup; Relation rel; - rel = heap_openr(ShadowRelationName, RowExclusiveLock); + rel = heap_openr(LanguageRelationName, RowExclusiveLock); tup = SearchSysCacheCopy(LANGNAME, CStringGetDatum(oldname), ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] BUG #1478: Upper function does not work
The following bug has been logged online: Bug reference: 1478 Logged by: Tiago Magalhães Vieira Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.0-rc5 Operating system: Windows XP Description:Upper function does not work Details: I have been experiencing some problems with the uppercase function, when the function has to make simple chars like 'c','a' etc it returns them in uppercase, but when it has to handle chars like 'á', 'é', 'ç' it does not do so. For example I have a field named 'med_type' in the table 'test' and one of this data in the field 'med_type' is 'Nutrição'. Then I make the query: SELECT upper(med_type) FROM test; It returns: 'NUTRIçãO' Even changed de characters enconding from UNICODE to ASCII and the problem still happens. Is this a bug or am I doing something wrong. Thanks in advance. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] BUG #1479: minor sintax
The following bug has been logged online:
Bug reference: 1479
Logged by: srdjan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: Linux hostname 2.4.18-3 #1 Thu Apr 18 07:31:07 EDT 2002
i586 unknown
Description:minor sintax
Details:
in file
postgresql-8.0.1/src/interfaces/ecpg/preproc/preproc.c +3620
replace '{' with ','
and compiler didn't exit with error something like
error in line . before')'
This is , ok , let say a patch.
3620c3620
< 1814, 25326, -2745, 1875, -2745, 1877, 931, -2745, 1599,10(
---
> 1814, 25326, -2745, 1875, -2745, 1877, 931, -2745, 1599,10,
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1479: minor sintax
srdjan wrote:
>
> The following bug has been logged online:
>
> Bug reference: 1479
> Logged by: srdjan
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0.1
> Operating system: Linux hostname 2.4.18-3 #1 Thu Apr 18 07:31:07 EDT 2002
> i586 unknown
> Description:minor sintax
> Details:
>
> in file
>
> postgresql-8.0.1/src/interfaces/ecpg/preproc/preproc.c +3620
>
> replace '{' with ','
>
> and compiler didn't exit with error something like
> error in line . before')'
>
> This is , ok , let say a patch.
> 3620c3620
> < 1814, 25326, -2745, 1875, -2745, 1877, 931, -2745, 1599,10(
> ---
> > 1814, 25326, -2745, 1875, -2745, 1877, 931, -2745, 1599,10,
Uh, that files is derived from preproc.y, and I don't see the "10("
anywhere in my version of that file. Perhaps it got corrupted somehow.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [BUGS] Bug in ALTER LANGUAGE ... RENAME TO ...;
Oh, good catch. We will fix that. Thanks. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Sergey N. Yatskevich wrote: > RenameLanguage procedure in src/backend/commands/proclang.c open > and update pg_catalog.pg_shadow table instead pg_catalog.pg_language. > > -- > Sergey N. Yatskevich <[EMAIL PROTECTED]> [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] Bug in ALTER LANGUAGE ... RENAME TO ...;
"Sergey N. Yatskevich" <[EMAIL PROTECTED]> writes: > RenameLanguage procedure in src/backend/commands/proclang.c open > and update pg_catalog.pg_shadow table instead pg_catalog.pg_language. Wow. Apparently this has been broken since it was written, and nobody ever tested it. Thanks! regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] PreparedStatement setObject
Kobus Walters wrote:
Create a prepared statement with sql "select localtimestamp - time ?". Call setObject(1, java.lang.String) with the String value "00:00:00" for instance. In version 7 this gets executed as "select localtimestamp - time '00:00:00'", while version 8 try to execute it as "select localtimestamp - time 00:00:00", which of cause fails since the quotes are missing.
I can't reproduce this. With the 8.0-310 driver against an 8.0.0 server,
I get a syntax error with that query:
ERROR: syntax error at or near "$1"
The query sent by the driver is:
SELECT LOCALTIMESTAMP - TIME $1
which the backend does not like. The change in behaviour from 7.4-era
drivers is because the 8.0 driver pushes handling of parameters to the
server, so you have to follow the server's rules for where you may place
parameters. Apparently, after TIME isn't one of those places.
To use a string as a time parameter, see the examples in my test code
(attached).
-O
import java.sql.*;
// Run with one argument: a JDBC url to connect to.
public class TestTime {
public static void main(String[] args) throws Exception {
Class.forName("org.postgresql.Driver");
Connection c = DriverManager.getConnection(args[0]);
// Works:
PreparedStatement s = c.prepareStatement("SELECT LOCALTIMESTAMP
- ?");
s.setObject(1, "00:00:00", Types.TIME);
// Works:
//PreparedStatement s = c.prepareStatement("SELECT
LOCALTIMESTAMP - {t '00:00:00'}");
// Breaks:
//PreparedStatement s = c.prepareStatement("SELECT
LOCALTIMESTAMP - TIME ?");
//s.setObject(1, "00:00:00", Types.TIME);
ResultSet rs = s.executeQuery();
rs.next();
System.err.println("returned " + rs.getObject(1));
rs.close();
s.close();
c.close();
}
}
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [BUGS] Bug in ALTER LANGUAGE ... RENAME TO ...;
> "Sergey N. Yatskevich" <[EMAIL PROTECTED]> writes: >> RenameLanguage procedure in src/backend/commands/proclang.c open >> and update pg_catalog.pg_shadow table instead pg_catalog.pg_language. > Wow. Apparently this has been broken since it was written, and > nobody ever tested it. Thanks! BTW, is there a security issue here? In my testing all I got was harmless "tuple concurrently updated" failures --- but it seems like this bug ought to result in either a core dump or storing a bogus row into pg_shadow. Neither of which sound appealing. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
