Re: [BUGS] Random hang during commit
>Does that mean 8.1.3 works fine on other PCs you have, but not this one? Yes, it is works fine with other PCs which do not have dual processor. (I can not find another machine has dual processor here) >If so, that suggests to me that there must be either: >1. A different library on the problem machine. No, same library are used. >2. Some process (firewall/antivirus) that is occasionally interfering with communication. No firewall/antivirus was running >Three things suggest themselves to me: >1. Make sure there aren't any known issues with the jdbc driver version you have http://jdbc.postgresql.org/ Seems not, but not sure about this one: http://jdbc.postgresql.org/todo.html#Known+Bugs [bugs] Deallocating large numbers of server side statements can break the connection by filling network buffers. This is a very, very low probability bug, but it is still possible. Actually, if using jdbc driver version 7.4 against database 8.1.3, this problem will not happen. It seems it is a bug relate with jdbc driver for a dual processor. >2. Check if there is anything unusual about the problem machine Nothing unusual >3. Try running the client on the problem machine and the database on another, then the other way around. Does this change anything? I tried both way and this problem seems never happen. -Original Message- From: Richard Huxton [mailto:[EMAIL PROTECTED] Sent: 14 March 2006 09:22 To: Lin, B (Bill) Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] Random hang during commit Bill - please cc: the bugs list too. Lin, B (Bill) wrote: > Some more information please. > 1. What operating-system? > XP SP2 > 2. Installed from a package (which) or source? >>From package > 3. What hangs - the client or the backend (or both)? > Both. The client is waiting for the backend's commit() to be completed. > 4. What do the logs show? > Usually, the last log shows commit is executed. >Hmm - if the log shows the commit happening that suggests the backend is doing its bit. It's not hanging, it's just idle waiting for the next query from >the client. That would mean that the problem is either in the client library, jdbc driver or the communication channel itself. >In your original message, you say: "I have installed same database, jdbc driver, jre and test case on some other computers. However, this problem will be >never happened on others." >Does that mean 8.1.3 works fine on other PCs you have, but not this one? >If so, that suggests to me that there must be either: >1. A different library on the problem machine. >2. Some process (firewall/antivirus) that is occasionally interfering with communication. >Three things suggest themselves to me: >1. Make sure there aren't any known issues with the jdbc driver version you have http://jdbc.postgresql.org/ >2. Check if there is anything unusual about the problem machine >3. Try running the client on the problem machine and the database on another, then the other way around. Does this change anything? -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Random hang during commit
Lin, B (Bill) wrote: >Does that mean 8.1.3 works fine on other PCs you have, but not this one? Yes, it is works fine with other PCs which do not have dual processor. (I can not find another machine has dual processor here) Ah, does your problem match what is being discussed here? http://archives.postgresql.org/pgsql-performance/2006-03/msg00032.php If so, that suggests to me that there must be either: 1. A different library on the problem machine. No, same library are used. 2. Some process (firewall/antivirus) that is occasionally interfering with communication. No firewall/antivirus was running Three things suggest themselves to me: 1. Make sure there aren't any known issues with the jdbc driver version you have http://jdbc.postgresql.org/ Seems not, but not sure about this one: http://jdbc.postgresql.org/todo.html#Known+Bugs [bugs] Deallocating large numbers of server side statements can break the connection by filling network buffers. This is a very, very low probability bug, but it is still possible. Hmm - doesn't sound like that's it. Actually, if using jdbc driver version 7.4 against database 8.1.3, this problem will not happen. It seems it is a bug relate with jdbc driver for a dual processor. Or possibly lower down even. 2. Check if there is anything unusual about the problem machine Nothing unusual 3. Try running the client on the problem machine and the database on another, then the other way around. Does this change anything? I tried both way and this problem seems never happen. Hmm - I'd have expected it to fail in one direction but not the other. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] Random hang during commit
Yes, It looks exactly same as http://archives.postgresql.org/pgsql-performance/2006-03/msg00032.php Only different is: in my case it happens in every 2 mins :) (I just found it is not only happen during commit, it could be during other sql call randomly) Thank you very much, at least I know what is the problem now. Bill -Original Message- From: Richard Huxton [mailto:[EMAIL PROTECTED] Sent: 15 March 2006 11:27 To: Lin, B (Bill) Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] Random hang during commit Lin, B (Bill) wrote: > >Does that mean 8.1.3 works fine on other PCs you have, but not this > one? > Yes, it is works fine with other PCs which do not have dual processor. > (I can not find another machine has dual processor here) Ah, does your problem match what is being discussed here? http://archives.postgresql.org/pgsql-performance/2006-03/msg00032.php >> If so, that suggests to me that there must be either: >> 1. A different library on the problem machine. > No, same library are used. >> 2. Some process (firewall/antivirus) that is occasionally interfering > with communication. > No firewall/antivirus was running > >> Three things suggest themselves to me: >> 1. Make sure there aren't any known issues with the jdbc driver >> version > you have http://jdbc.postgresql.org/ > Seems not, but not sure about this one: > http://jdbc.postgresql.org/todo.html#Known+Bugs > [bugs] Deallocating large numbers of server side statements can break > the connection by filling network buffers. This is a very, very low > probability bug, but it is still possible. Hmm - doesn't sound like that's it. > Actually, if using jdbc driver version 7.4 against database 8.1.3, > this problem will not happen. > It seems it is a bug relate with jdbc driver for a dual processor. Or possibly lower down even. >> 2. Check if there is anything unusual about the problem machine > Nothing unusual >> 3. Try running the client on the problem machine and the database on > another, then the other way around. Does this change anything? > I tried both way and this problem seems never happen. Hmm - I'd have expected it to fail in one direction but not the other. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] Large join runs out of memory in 8.1
On Tue, Mar 14, 2006 at 11:29:57PM -0500, Tom Lane wrote: > It's not the easiest sort of problem to debug :-( ... > > What I'd try is first letting the problem case run for a bit, then > stopping it with gdb and dumping out a few Kb of the frontmost memory > block in the ExecutorState context. Sometimes, looking at the data Can you point me a little more in that direction? I can't figure out how to get a handle to that context. > that's being leaked is enough to give you a clue. If not, try setting a > breakpoint at AllocSetAlloc and trying to see where the majority of > calls are coming from. It'll be tedious ... This is the pattern I seemed to get: 3 calls here: #0 0x1021aa80 in AllocSetAlloc () #1 0x1021ba0c in MemoryContextAlloc () #2 0x1016de48 in BufFileCreateTemp () #3 0x100fcbb4 in ExecHashJoinSaveTuple () #4 0x100fbe44 in ExecHashTableInsert () #5 0x100fc858 in MultiExecHash () #6 0x100ef6d8 in MultiExecProcNode () #7 0x100fd800 in ExecHashJoin () #8 0x100ef8a8 in ExecProcNode () #9 0x100edea8 in ExecutorRun () #10 0x1018519c in ProcessQuery () #11 0x10185850 in PortalRun () #12 0x1018084c in exec_simple_query () #13 0x101825b0 in PostgresMain () #14 0x1015510c in ServerLoop () #15 0x10155d80 in PostmasterMain () #16 0x101101e8 in main () 1 call here: #0 0x1021aa80 in AllocSetAlloc () #1 0x1021bb1c in MemoryContextAllocZero () #2 0x100324d4 in heap_form_tuple () #3 0x100f5810 in ExecCopySlotTuple () #4 0x100f5c04 in ExecMaterializeSlot () #5 0x100fc848 in MultiExecHash () #6 0x100ef6d8 in MultiExecProcNode () #7 0x100fd800 in ExecHashJoin () #8 0x100ef8a8 in ExecProcNode () #9 0x100edea8 in ExecutorRun () #10 0x1018519c in ProcessQuery () #11 0x10185850 in PortalRun () #12 0x1018084c in exec_simple_query () #13 0x101825b0 in PostgresMain () #14 0x1015510c in ServerLoop () #15 0x10155d80 in PostmasterMain () #16 0x101101e8 in main () 1 call here: #0 0x1021aa80 in AllocSetAlloc () #1 0x1021ba0c in MemoryContextAlloc () #2 0x1016c530 in make_database_relative () #3 0x1016cf7c in FileNameOpenFile () #4 0x1016d02c in OpenTemporaryFile () #5 0x1016de10 in BufFileCreateTemp () #6 0x100fcbb4 in ExecHashJoinSaveTuple () #7 0x100fbe44 in ExecHashTableInsert () #8 0x100fc858 in MultiExecHash () #9 0x100ef6d8 in MultiExecProcNode () #10 0x100fd800 in ExecHashJoin () #11 0x100ef8a8 in ExecProcNode () #12 0x100edea8 in ExecutorRun () #13 0x1018519c in ProcessQuery () #14 0x10185850 in PortalRun () #15 0x1018084c in exec_simple_query () #16 0x101825b0 in PostgresMain () #17 0x1015510c in ServerLoop () #18 0x10155d80 in PostmasterMain () #19 0x101101e8 in main () Repeat. --Joe -- Joe Sunday <[EMAIL PROTECTED]> http://www.csh.rit.edu/~sunday/ Computer Science House, Rochester Inst. Of Technology ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Large join runs out of memory in 8.1
Joe Sunday <[EMAIL PROTECTED]> writes: > On Tue, Mar 14, 2006 at 11:29:57PM -0500, Tom Lane wrote: >> What I'd try is first letting the problem case run for a bit, then >> stopping it with gdb and dumping out a few Kb of the frontmost memory >> block in the ExecutorState context. Sometimes, looking at the data > Can you point me a little more in that direction? I can't figure out how > to get a handle to that context. Well, it's nearly hopeless with a non-debug build, which is what you seem to have there :-(. With debug symbols, printing the parameter passed to AllocSetAlloc is easy enough. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] Large join runs out of memory in 8.1
On Wed, Mar 15, 2006 at 01:10:41PM -0500, Tom Lane wrote:
> Joe Sunday <[EMAIL PROTECTED]> writes:
> > On Tue, Mar 14, 2006 at 11:29:57PM -0500, Tom Lane wrote:
> >> What I'd try is first letting the problem case run for a bit, then
> >> stopping it with gdb and dumping out a few Kb of the frontmost memory
> >> block in the ExecutorState context. Sometimes, looking at the data
>
> > Can you point me a little more in that direction? I can't figure out how
> > to get a handle to that context.
>
> Well, it's nearly hopeless with a non-debug build, which is what you
> seem to have there :-(. With debug symbols, printing the parameter
> passed to AllocSetAlloc is easy enough.
Sorry, stupid moment there.
#0 AllocSetAlloc (context=0x10360918, size=160) at aset.c:510
#1 0x1021bb78 in MemoryContextAllocZero (context=0x10360918, size=160)
at mcxt.c:529
#2 0x100324dc in heap_form_tuple (tupleDescriptor=0x1036fc80,
values=0x10370088, isnull=0x103700b0 "") at heaptuple.c:727
#3 0x100f586c in ExecCopySlotTuple (slot=0x1021aaa8) at execTuples.c:558
#4 0x100ee6dc in ExecutorRun (queryDesc=0x10365858, direction=272041248,
count=0) at execMain.c:1349
#5 0x101851f8 in ProcessQuery (parsetree=0x1036be38, plan=0x10364db0,
params=0x0, dest=0x102d, completionTag=0xcc00 "") at pquery.c:174
#6 0x101858ac in PortalRun (portal=0x103676c0, count=2147483647,
dest=0x10363ef0, altdest=0x10363ef0, completionTag=0xcc00 "")
at pquery.c:1069
#7 0x101808a8 in exec_simple_query (
query_string=0x10359208 "SELECT a.key_a, a.key_b, \n a.column1, a.column2,
a.column3,\n b.local_a, b.local_b\nINTO TEMP x\nFROM a a, b b \nWHERE a.key_a
= b.key_a \n AND a.key_b = b.key_b\n AND b.local_a is not null;")
at postgres.c:1002
(gdb) print {AllocSetContext}0x10360918
$11 = {header = {type = T_AllocSetContext, methods = 0x102cd198,
parent = 0x10360890, firstchild = 0x103611b8, nextchild = 0x0,
name = 0x10360970 "ExecutorState"}, blocks = 0x960fb008, freelist = {0x0,
0x10370d50, 0x103702e8, 0x103702a0, 0x10373578, 0x10370518, 0x10370730,
0x10370938, 0x0, 0x0, 0x103714b0}, isReset = 0 '\0', initBlockSize = 8192,
maxBlockSize = 8388608, keeper = 0x103656a0}
The first block isn't anything I recognize:
0x960fb008: 0x10360918 0x96ec7c18 0x96101528 0x968fb008
0x960fb018: 0x10360918 0x0008 0x2000 0x
0x960fb028: 0x10360918 0x0008 0x0003fc03 0x
0x960fb038: 0x10360918 0x0008 0x 0x
0x960fb048: 0x10360918 0x0008 0x0003fc04 0x
0x960fb058: 0x10360918 0x0008 0x 0x
0x960fb068: 0x10360918 0x0008 0x0003fc05 0x
0x960fb078: 0x10360918 0x0008 0x 0x
0x960fb088: 0x10360918 0x0008 0x0003fc06 0x
0x960fb098: 0x10360918 0x0008 0x 0x
0x960fb0a8: 0x10360918 0x0008 0x0003fc07 0x
0x960fb0b8: 0x10360918 0x0008 0x 0x
0x960fb0c8: 0x10360918 0x0008 0x0003fc08 0x
0x960fb0d8: 0x10360918 0x0008 0x 0x
0x960fb0e8: 0x10360918 0x0008 0x0003fc09 0x
0x960fb0f8: 0x10360918 0x0008 0x 0x
0x960fb108: 0x10360918 0x0008 0x0003fc0a 0x
0x960fb118: 0x10360918 0x0008 0x2000 0x
0x960fb128: 0x10360918 0x0008 0x0003fc0b 0x
0x960fb138: 0x10360918 0x0008 0x 0x
0x960fb148: 0x10360918 0x0008 0x0003fc0c 0x
0x960fb158: 0x10360918 0x0008 0x 0x
0x960fb168: 0x10360918 0x0008 0x0003fc0d 0x
(and so on)
The next block looks like the contents of table a.
I'm still working a minimal test case that exhibits the same problem.
--Joe
--
Joe Sunday <[EMAIL PROTECTED]> http://www.csh.rit.edu/~sunday/
Computer Science House, Rochester Inst. Of Technology
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2313: Installation on a FAT32 partition
The following bug has been logged online: Bug reference: 2313 Logged by: Francisco de Assis Carvalho da Silva Neto Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: Windows XP Description:Installation on a FAT32 partition Details: When installing Postgre on a FAT32 partition many people get the following message when trying to start the database server service manually: "The PostgreSQL Database Server 8.1 service was started on local computer and stopped. Some services are automatically stopped when they are idling, like alarm services and performance protocolling services." This happens because one did not create the database cluster in the \data folder inside postgre folder and initdb.exe does not registry the service correctly, it always registry the server service for the default folder. In order to solve this problem, one must change the windows registry [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\pgsql-8.1] and change variable "ImagePath" to the path where the database cluster was created. I think it might be useful for many people. ---(end of broadcast)--- TIP 1: 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 #2312: Software caused connection abort (0x00002745/10053) with long Bytea (>4.5mb) in the query
The following bug has been logged online: Bug reference: 2312 Logged by: inner Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.2 Operating system: Windows XP pro Description:Software caused connection abort (0x2745/10053) with long Bytea (>4.5mb) in the query Details: Client application tries to execute query with Bytea quoted parameter. When size of Bytea param is less than 4.5 mb query executes fine. But when size of bytea param is more than 4.5mb (5mb e.g.) then raises exception: --- Software caused connection abort (0x2745/10053) --- Server says: "could not receive data from client". and doing "unexpected EOF on client connection". Reading archives of postresql.org i find out, that it can be problem of tcp_alive parameters in windows. Please, tell me definitely is that normal limitation for bytea on windows platform? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #2315: Crash engine after modify "active" function
The following bug has been logged online: Bug reference: 2315 Logged by: Alexander Kirpa Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: FreeBSD 6.0 Description:Crash engine after modify "active" function Details: FUNCTION f1(text, int4) DECLARE BEGIN ... id:=f2(ww); ... RETURN xx; END; FUNCTION f2(text) SELECT f1(c1) FROM t1, where table t1 big for long run During run, simple modify function f2, no any serious internal changes within function, only move some string for change application logic. After write (commit) function changes over pgadmin Postgres engine crash -- 2006-03-12 13:31:06 EET 502 LOG: server process (PID 28569) was terminated by signal 11 2006-03-12 13:31:06 EET 502 LOG: terminating any other active server processes ... 2006-03-12 13:31:06 EET 502 LOG: all server processes terminated; reinitializing 2006-03-12 13:31:06 EET 44181 LOG: database system was interrupted at 2006-03-12 13:29:19 EET 2006-03-12 13:31:06 EET 44181 LOG: checkpoint record is at 22/E186B310 2006-03-12 13:31:06 EET 44181 LOG: redo record is at 22/E181F434; undo record is at 0/0; shutdown FALSE 2006-03-12 13:31:06 EET 44181 LOG: next transaction ID: 82131; next OID: 61399 2006-03-12 13:31:06 EET 44181 LOG: next MultiXactId: 1; next MultiXactOffset: 0 2006-03-12 13:31:06 EET 44181 LOG: database system was not properly shut down; automatic recovery in progress 2006-03-12 13:31:06 EET 44181 LOG: redo starts at 22/E181F434 2006-03-12 13:31:06 EET 44181 LOG: record with zero length at 22/E253D24C 2006-03-12 13:31:06 EET 44181 LOG: redo done at 22/E253D224 2006-03-12 13:31:07 EET 44181 LOG: database system is ready - After restart I do not see any PG engine problem and second crash during modify top level function f1 under heavy using f1 2006-03-12 19:50:53 EET 502 LOG: server process (PID 44308) was terminated by signal 10 2006-03-12 19:50:53 EET 502 LOG: terminating any other active server processes 2006-03-12 19:50:53 EET 502 LOG: all server processes terminated; reinitializing 2006-03-12 19:50:53 EET 45055 LOG: database system was interrupted at 2006-03-12 19:49:50 EET 2006-03-12 19:50:53 EET 45055 LOG: checkpoint record is at 24/F17E3F8C 2006-03-12 19:50:53 EET 45055 LOG: redo record is at 24/F0528C1C; undo record is at 0/0; shutdown FALSE 2006-03-12 19:50:53 EET 45055 LOG: next transaction ID: 83765; next OID: 69591 2006-03-12 19:50:53 EET 45055 LOG: next MultiXactId: 10; next MultiXactOffset: 19 2006-03-12 19:50:53 EET 45055 LOG: database system was not properly shut down; automatic recovery in progress 2006-03-12 19:50:53 EET 45055 LOG: redo starts at 24/F0528C1C 2006-03-12 19:50:58 EET 45055 LOG: record with zero length at 24/F80473C4 2006-03-12 19:50:58 EET 45055 LOG: redo done at 24/F8047384 2006-03-12 19:50:59 EET 45055 LOG: database system is ready 2006-03-12 19:50:59 EET 45055 LOG: transaction ID wrap limit is 1073824976, limited by database "shorttest" 2006-03-12 19:50:59 EET 45058 LOG: invalid server process ID -1 2006-03-12 19:50:59 EET 45058 LOG: invalid server process ID -1 Possible reason - no transaction isolation for function. Best regards, Alexander Kirpa ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2319: psql utf8/latin1 client_encoding bug when using '-c'
The following bug has been logged online: Bug reference: 2319 Logged by: Mattias Kregert Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.0 Operating system: Linux 2.4 Description:psql utf8/latin1 client_encoding bug when using '-c' Details: Psql '-c' does not work when using client_encoding. Example: Server has encoding UTF8, client has encoding latin1 -- This works... % psql -h server mydb mydb=# set client_encoding to 'latin1'; mydb=# select * from mytable where text='Ã ÃÃ'; -- ...but this does not. % psql -h server mydb -c "set client_encoding to 'latin1'; select * from mytable where text='Ã ÃÃ';" ERROR: invalid UTF-8 byte sequence detected near byte 0xc5 I tried this too, without success: % psql --set encoding=latin1 -h server mydb ... ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] problems with renaming a column of type serial & pg_dump
Name: Alexis Wilke
email: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating System: Linux RedHat 9.0
Short Description: problems with renaming a column of type serial
and GRANT/REVOKE instructions in pg_dump
Details:
Hi guys,
I have been working on a database for a while and just today tried to
restore a dump of it. (I have an automatic dump created every night for
safe keeping).
This is when I noticed a problem with several columns of type serial which
I had renamed. The sequence functioning worked fine, but the sequence
references in the GRANT/REVOKE commands weren't renamed.
According to the release notes of version 8.1.0, Tom has fixed it, however
he mentions problems with DEFAULT values and not GRANT/REVOKE. So I'm
still posting this bug in case the fix was not enough for the entire
functionality of a database.
Please, see the attached .sql file which includes instructions on how
to run it
--
Alexis Wilke
President
Made to Order Software, Corporation
Made to Order Software, Limited
e-mail: [EMAIL PROTECTED]
cell-text: [EMAIL PROTECTED] (please, only small messages)
Web Page: http://www.m2osw.com
Company e-mail: [EMAIL PROTECTED]
Phone: +(1) 916 220 6482
Fax:+(1) 916 988 1450
Address 1: 9275 Blue Oak Drive
Orangevale, California 95662
United States of America
Address 2: 2nd Floor, Hammersmith Broadway
Hammersmith
London W6 7BB
United Kingdom
CONFIDENTIAL
This document contains non-public proprietary information
that is subject to restrictions on use and/or disclosure.
If you are not the intended recipient, any dissemination,
distribution or copying is strictly prohibited. If you
think that you have received this e-mail message in error,
please e-mail the sender and delete all copies. Thank you.
--
-- With Postgres version 8.0.1
--
-- Renaming a column which is attached to a sequence is bogus
-- when that sequence had some specific granted rights
--
-- Commands:
--
-- [ONCE:]
-- bash> psql template1
-- psql> CREATE DATABASE rename_bug;
-- psql> \q
--
-- [REPEAT AS REQUIRED:]
-- bash> psql -f rename-bug.sql
-- bash> pg_dump rename_bug
--
-- IMPORTANT NOTE:
-- The psql -f rename-bug.sql command will generate two errors
-- the first time since the my_table table and rename_bug group
-- do not exist yet.
--
-- The problem: the pg_dump will print out the sequence as
-- my_table_unique_id_seq in the list of REVOKE/GRANT, whereas
-- in the SELECT ... setvalue() ...; the renamed column appears
-- properly as my_table_serial_id_seq
-- We would either need both to be renamed or neither.
-- [or, as Tom pointed out in Release Notes 8.1.0 : we should use
-- an oid and not the actual name]
--
-- Note that the renamed column works properly in the original
-- database, only pg_dump gets it wrong... it seems.
--
-- IMPORTANT: it seems this is a problem with the index files too.
-- (i.e. with column setup as 'unique')
--
DROP TABLE my_table;
CREATE TABLE my_table (
unique_id serial,
nametext
);
-- INSERT INTO my_table (name) VALUES ('Rename Bug');
DROP GROUP rename_bug;
CREATE GROUP rename_bug;
GRANT SELECT ON TABLE my_table TO GROUP rename_bug;
GRANT SELECT ON TABLE my_table_unique_id_seq TO GROUP rename_bug;
ALTER TABLE my_table RENAME COLUMN unique_id TO serial_id;
---(end of broadcast)---
TIP 1: 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 #2317: Wrong sorting order for (VW)
The following bug has been logged online: Bug reference: 2317 Logged by: TomasKlockar Email address: [EMAIL PROTECTED] PostgreSQL version: 7.3.2/7.4.7 Operating system: linux(fedora) Description:Wrong sorting order for (VW) Details: SELECT cname FROM clients ORDER BY cname; sorts W before V and that is a mistake. the result is V W WHI Vi Wi Volvo Correct order would be to place all vV before all wW. I think the database was initialized with UTF8 but it might have been ISO_8859-1, however the error is easily repeatable and ill be happy to provide a dump. I tested this on 7.3.2 and 7.4.7 and the error was repeatable. regards, /Tomas ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #2318: language
The following bug has been logged online: Bug reference: 2318 Logged by: Mete Akdogan Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3-1 Operating system: win-xp Description:language Details: hi, i am a teaching assistant in www.deu.edu.tr, in one of our db courses, we are planning to teach from postgresql. but pgadmin's language is changing to Turkish due to opsys regional settings. Is there anyway to keep its language English without changing the regional settings' location. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] BUG #2316: problems when Restore Backup in RHEL4
The following bug has been logged online: Bug reference: 2316 Logged by: Teofilo Santos Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: Red Hat Enterprise Linux 4 Description:problems when Restore Backup in RHEL4 Details: I made a pg_dumpall in a postgresql server without problems (using Red Hat 9. and postgresql 8.0.3), but when i attempt to restore this backup in a RHEL4 (kernel 2.6.9-5 64 bits )i receive a lot of erros: invalid command \n! I try to use Fedora Core 4 and i restore the the backup perfectly. I used: # pg_dumpall -U postgres > mybackup # pqsl -U postgres template1 < mybackup I think that i´m doing all the procedures right. Could you help me! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2314: The Order changed?
The following bug has been logged online: Bug reference: 2314 Logged by: L.Jumadi Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: SimplyMepis 3.4.3 with kernel 2.6.15.2 Description:The Order changed? Details: I have a table named test with field like this: ocode varchar(8), code varchar(8) with primary key at ocode.With data like this: ocode code 'test''-0' 'test''-1' 'test''1' 'test''2' I give the command in the psql like this: SELECT * FROM test ORDER BY code; the result is like this: ocode code test-0 test1 test-1 test2 When I use 8.0.1 version this command gives me result like this ocode code test-0 test-1 test1 test2 The question is this a bug?or there is changes in the way postgreSQL order the field? Thank's in advance ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2314: The Order changed?
On Sun, 12 Mar 2006, L.Jumadi wrote: > > The following bug has been logged online: > > Bug reference: 2314 > Logged by: L.Jumadi > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.3 > Operating system: SimplyMepis 3.4.3 with kernel 2.6.15.2 > Description:The Order changed? > Details: > > I have a table named test with field like this: > ocode varchar(8), code varchar(8) with primary key > at ocode.With data like this: > ocode code > 'test''-0' > 'test''-1' > 'test''1' > 'test''2' > I give the command in the psql like this: > SELECT * FROM test ORDER BY code; > the result is like this: > ocode code > test-0 > test1 > test-1 > test2 > When I use 8.0.1 version this command gives me result > like this > ocode code > test-0 > test-1 > test1 > test2 > The question is this a bug?or there is changes in the > way postgreSQL order the field? Thank's in advance The most likely explanation is that the locale choice at initdb time for the two versions was different. The 8.0 result looks consistent with "C" locale and the 8.1 with some others (like en_US). For example: [EMAIL PROTECTED] test]$ cat file -0 -1 1 2 [EMAIL PROTECTED] test]$ LANG="C" sort file -0 -1 1 2 [EMAIL PROTECTED] test]$ LANG="en_US" sort file -0 1 -1 2 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2317: Wrong sorting order for (VW)
On Mon, 13 Mar 2006, TomasKlockar wrote: > > The following bug has been logged online: > > Bug reference: 2317 > Logged by: TomasKlockar > Email address: [EMAIL PROTECTED] > PostgreSQL version: 7.3.2/7.4.7 > Operating system: linux(fedora) > Description:Wrong sorting order for (VW) > Details: > > SELECT cname FROM clients ORDER BY cname; > > sorts W before V and that is a mistake. > > the result is > > V > W > WHI > Vi > Wi > Volvo > > Correct order would be to place all vV before all wW. > > I think the database was initialized with UTF8 but it might have been > ISO_8859-1, however the error is easily repeatable and ill be happy to > provide a dump. > > I tested this on 7.3.2 and 7.4.7 and the error was repeatable. I think the most important thing we'd need to know is what locale the database was initialized with in order to try to reproduce. If you put similar data in a file and use the unix "sort" command with the same locale, do you get the same order? ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2315: Crash engine after modify "active" function
"Alexander Kirpa" <[EMAIL PROTECTED]> writes: > Description:Crash engine after modify "active" function I can't reproduce this in HEAD. I think it's probably the same bug already reported here: http://archives.postgresql.org/pgsql-bugs/2006-03/msg6.php and fixed here: http://archives.postgresql.org/pgsql-committers/2006-03/msg00022.php regards, tom lane ---(end of broadcast)--- TIP 1: 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] BUG #2319: psql utf8/latin1 client_encoding bug when using '-c'
"Mattias Kregert" <[EMAIL PROTECTED]> writes: > -- ...but this does not. > % psql -h server mydb -c "set client_encoding to 'latin1'; select * from > mytable where text='Ã ÃÃ';" > ERROR: invalid UTF-8 byte sequence detected near byte 0xc5 There is no hope of that ever working, since the string will be read (and converted to the server's encoding if relevant) before the SET is executed. Better find another way to do what you want. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #2317: Wrong sorting order for (VW)
"TomasKlockar" <[EMAIL PROTECTED]> writes: > I think the database was initialized with UTF8 but it might have been > ISO_8859-1, however the error is easily repeatable and ill be happy to > provide a dump. If the database encoding doesn't match the database locale (server LC_COLLATE setting), all kinds of very strange sorting behavior can ensue. I suspect you've been bit by this gotcha. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2316: problems when Restore Backup in RHEL4
"Teofilo Santos" <[EMAIL PROTECTED]> writes: > I made a pg_dumpall in a postgresql server without problems (using Red Hat > 9. and postgresql 8.0.3), but when i attempt to restore this backup in a > RHEL4 (kernel 2.6.9-5 64 bits )i receive a lot of erros: invalid command > \n! If you're using the RHEL4 version of Postgres (ie, 7.4.something), this is unlikely to work --- dump files are very often not portable to older server versions without manual editing, because they'll use new SQL features that the older server doesn't understand. Try paying attention to the *first* reported error, not the subsequent ones, to get a better handle on what's going wrong. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2318: language
On Tue, Mar 14, 2006 at 09:30:29AM +, Mete Akdogan wrote: > > The following bug has been logged online: > > Bug reference: 2318 [...] This is not a bug (and definitely not a PostgreSQL bug ;-) > hi, i am a teaching assistant in www.deu.edu.tr, in one of our db courses, > we are planning to teach from postgresql. but pgadmin's language is changing > to Turkish due to opsys regional settings. [...] Just give pgadmin another environment: from the command line type export LANG=C pgadmin & If you are using a graphical desktop you then can install a command line lime this in the starter button/menu for pgadmin. signature.asc Description: Digital signature
