[BUGS] Multibyte characters handling bug in varchar()

2002-07-10 Thread Edward 



Hello,
 
I am using Postgresql 7.1 on Linux platform (RedHat 
7.1).
 
My database encoding is 'EUC_CN'.
 
The application is accessing database with PG 
JDBC2.0.
 
I had define a field in a table like:
 
create table test1 (
 
id integer default not null,
memo varchar(128)
 
 
);
 
The memo field is for user to record some comment or alike. 
They input Chinese (GB2312 or GBK encoding) mixed with ASCII.
 
Problem happens when:
 
The length of the input string is larger than 128,  and 
the 128th and 129th byte consists of a Chinese character (you know Chinese 
characters use two bytes in GB2312 or GBK encoding).
 
The problem is:
 
The insert query will be running well without any error. But 
the getString method will get a zero length String from the field.
 
More complications:
 
When I pg_dump the database and restore it, the scripts 
produced by pg_dump (with -D flag, which means dump with attribute) can not 
be restored. When I check the scripts I found that the memo field of this record 
is dumped without the ending single quote (this is because the 128th byte and 
the single quote followed acutally consists of another unrecognized chinese 
character) and that is why it failed to be restored.
 
Below is the dump for this record:
 
INSERT INTO 
"test1" ("id","memo") VALUES 
(5,'Ò¨°¡Á¡»¡ìͶËßµÄÊÇÒÀɽ¾ÓGHµ¥ÔªÕûÌåÇ彨¤Ö¡ÂÒªÊÇ5ÔÂ1ÈÕÖÁ3ÈÕÒ¨°µÚÒ»¾Ó¿ªÅÌ¡ã²ÅÅÁËһλÐÂÔ¡À¹¡è¶¥ÌæÁ˼¸Ì¨¬£¬ÍϵØÊ¡Àˮû¡Á¢Òâѹ¸ÉÖÂʹҵ֡ÂͶËßÒÑҪǨ®Ë');
 
 
I feel the Multibyte is not properly handled in this case. 
Looking forward to hearing from dev team.
 
Finally I think PostgreSQL is an excellent database, but the 
name postgresql seems very difficult to pronounce and it is probably one 
obstacle preventing people knowing more about it.
 
Thanks for the hardworking of the dev team, you have done 
excellent work!
 
Best Regards,
 
 
 

[BUGS] BUG #1982: pgAdmin 1.2.2 crash when refreshing objects

2005-10-21 Thread edward 

The following bug has been logged online:

Bug reference:  1982
Logged by:  edward
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system:   Win2000 WS
Description:pgAdmin 1.2.2 crash when refreshing objects
Details: 

how to recreate crash in pgAdmin 1.2.2 on W2K
1. open application and connect to my_db
2. navigate on left panel:
   open db->my_db->schemes->public->tables->my_table
3. open child window to edit/review the table layout
4. don't accept changes, but push refresh button on the toolbar of the main
pgAdmin window
5. try to accept changes now on the child window

Application crashes with the message "memory access violation"

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

[BUGS] BUG #6671: Killed restore command causes postmaster to exit

2012-05-31 Thread edward 
The following bug has been logged on the website:

Bug reference:  6671
Logged by:  Ed Muller
Email address:  edw...@heroku.com
PostgreSQL version: 9.0.7
Operating system:   Linux (Ubuntu 10.04)
Description:

We have this thing where we kill the restore command sometimes, to ensure
it's not stuck. 

This has rarely led to postmaster dying afterwards instead of retrying.

Here are some related logs...

[CRIMSON] LOG:  restored log file "000631B50099" from archive

[CRIMSON] FATAL:  could not restore file "000631B5009A" from
archive: return code 36608

[CRIMSON] LOG:  startup process (PID 854) exited with exit code 1

[CRIMSON] LOG:  terminating any other active server processes


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #7627: Bad query plan when using LIMIT

2012-10-29 Thread edward 
The following bug has been logged on the website:

Bug reference:  7627
Logged by:  Edward Faulkner
Email address:  edw...@clericare.com
PostgreSQL version: 9.2.1
Operating system:   OSX 10.8.2
Description:

The following two queries differ only by adding "LIMIT 1", but the one with
the limit gets radically worse performance. I've done VACUUM FULL, VACUUM
ANALYZE, and REINDEX DATABASE and there are no modifications since.

EXPLAIN ANALYZE SELECT * FROM commits WHERE id IN (SELECT id FROM commits
ORDER BY tree_high LIMIT 605 ) AND tree_other IS NULL ORDER BY tree_high
DESC;
 
QUERY PLAN  

---
 Sort  (cost=4665.10..4666.59 rows=595 width=173) (actual
time=27.936..28.034 rows=543 loops=1)
   Sort Key: public.commits.tree_high
   Sort Method: quicksort  Memory: 169kB
   ->  Nested Loop  (cost=60.93..4637.68 rows=595 width=173) (actual
time=2.000..26.658 rows=543 loops=1)
 ->  HashAggregate  (cost=60.93..66.98 rows=605 width=28) (actual
time=1.880..2.214 rows=605 loops=1)
   ->  Subquery Scan on "ANY_subquery"  (cost=0.00..59.42
rows=605 width=28) (actual time=0.034..1.231 rows=605 loops=1)
 ->  Limit  (cost=0.00..53.37 rows=605 width=32) (actual
time=0.032..0.941 rows=605 loops=1)
   ->  Index Scan using commit_tree on commits 
(cost=0.00..13481.52 rows=152837 width=32) (actual time=0.031..0.799
rows=605 loops=1)
 ->  Index Scan using commits_pkey on commits  (cost=0.00..7.54
rows=1 width=173) (actual time=0.038..0.039 rows=1 loops=605)
   Index Cond: ((id)::text = ("ANY_subquery".id)::text)
   Filter: (tree_other IS NULL)
   Rows Removed by Filter: 0
 Total runtime: 28.210 ms
(13 rows)

EXPLAIN ANALYZE SELECT * FROM commits WHERE id IN (SELECT id FROM commits
ORDER BY tree_high LIMIT 605 ) AND tree_other IS NULL ORDER BY tree_high
DESC LIMIT 1;
 
QUERY PLAN  

---
 Limit  (cost=0.00..2314.68 rows=1 width=173) (actual
time=46626.438..46626.439 rows=1 loops=1)
   ->  Nested Loop Semi Join  (cost=0.00..1377233.62 rows=595 width=173)
(actual time=46626.437..46626.437 rows=1 loops=1)
 Join Filter: ((public.commits.id)::text =
("ANY_subquery".id)::text)
 Rows Removed by Join Filter: 90573339
 ->  Index Scan Backward using commit_tree on commits 
(cost=0.00..13481.52 rows=150269 width=173) (actual time=0.025..406.336
rows=149708 loops=1)
   Filter: (tree_other IS NULL)
   Rows Removed by Filter: 2525
 ->  Materialize  (cost=0.00..62.44 rows=605 width=28) (actual
time=0.000..0.084 rows=605 loops=149708)
   ->  Subquery Scan on "ANY_subquery"  (cost=0.00..59.42
rows=605 width=28) (actual time=0.027..1.166 rows=605 loops=1)
 ->  Limit  (cost=0.00..53.37 rows=605 width=32) (actual
time=0.026..0.965 rows=605 loops=1)
   ->  Index Scan using commit_tree on commits 
(cost=0.00..13481.52 rows=152837 width=32) (actual time=0.026..0.828
rows=605 loops=1)
 Total runtime: 46626.562 ms
(12 rows)

It's possible to work around the problem like this:

EXPLAIN ANALYZE WITH candidates AS (SELECT * FROM commits WHERE id IN
(SELECT id FROM commits ORDER BY tree_high LIMIT 605 ) AND tree_other IS
NULL) SELECT * FROM candidates ORDER BY tree_high DESC LIMIT 1;
  
QUERY PLAN  
 
-
 Limit  (cost=4652.56..4652.56 rows=1 width=436) (actual time=29.369..29.370
rows=1 loops=1)
   CTE candidates
 ->  Nested Loop  (cost=60.93..4637.68 rows=595 width=173) (actual
time=2.008..27.454 rows=543 loops=1)
   ->  HashAggregate  (cost=60.93..66.98 rows=605 width=28) (actual
time=1.891..2.271 rows=605 loops=1)
 ->  Subquery Scan on "ANY_subquery"  (cost=0.00..59.42
rows=605 width=28) (actual time=0.032..1.237 rows=605 loops=1)
   ->  Limit  (cost=0.00..53.37 rows=605 width=32)
(actual time=0.031..0.909 rows=605 loops=1)
 ->  Index

Re: [BUGS] Bug #640: ECPG: inserting float numbers

2002-04-30 Thread Edward Pilipczuk 

On Monday, 22 April 2002 18:41, you wrote:
> Edward ([EMAIL PROTECTED]) reports a bug with a severity of 1
> The lower the number the more severe it is.
>
> Short Description
> ECPG: inserting float numbers
>
> Long Description
> Inserting records with single precision real variables having small value
> (range 1.0e-6 or less) frequently results in errors in ECPG translations
> putting into resulted sql statement unexpected characters => see fragments
> of sample code and ECPGdebug log where after value of rate variable the
> unexpected character '^A' appears
>
> Sample Code
> /* fragment of the program code */
> exec sql begin declare section;
> /* ... */
> float rate;   /* level change rate  */
> /* ... */
> exec sql end declare section;
> /* ... */
> sprintf(buf,"INSERT: %.8s.%.8s @%.32s -> %08x/%08x %f %f %f %f %f", loc,
> name, ts, devstat, meastat, relative, level, ullage, rate, volume );
> dbg_message( __FILE__, __LINE__, DBG_DBI, MSG_SQL, buf );
> exec sql INSERT INTO rdr_meas ( name, loc, ts, devstat, meastat, relative,
> level, ullage, levelrate, volume ) VALUES ( :name, :loc, 'now', :devstat,
> :meastat, :relative, :level, :ullage, :rate, :volume ) ; /* ... */
> ---
> The above produces in ECPG debug :
> ...
> [2782]: ECPGexecute line 1042: QUERY: insert into rdr_meas ( name  , loc  ,
> ts  , devstat  , meastat  , relative  , level  , ullage  , levelrate  ,
> volume  ) values ( 'NR1 ' , 'Swedwood' , 'now' , 0 , 4096 ,
> 37.388961791992 , 0.71039032936096 , 1.1896096467972 , -5.5060195336409e-06
> ^A , 3.4871203899384 ) on connection radar [2782]: ECPGexecute line 1042:
> Error: ERROR:  parser: parse error at or near "^A" [2782]: raising sqlcode
> -400 in line 1042, ''ERROR:  parser: parse error at or near "^A"' in line
> 1042.'.
>
>
> No file was uploaded with this report
>
--
I am fighting with this bug on "PostgreSQL 7.2 on i686-pc-linux-gnu, compiled 
by GCC 2.96". It appears also on 7.1.x, which was reported previously 
(see buglist -> ecpg: unstable INSERT operation) on August 2001.
The temporary workaround I apllied here is "if" statement before INSERT:
if( fabs( rate ) < 1.0e-3 ) rate = 0.0;

Edward

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

[BUGS] BUG #1508: Install problem and workaround

2005-02-27 Thread Edward Jones 

The following bug has been logged online:

Bug reference:  1508
Logged by:  Edward Jones
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.01
Operating system:   XP Professional
Description:Install problem and workaround
Details: 

Initial attempts at installing Postgres 8.0.1 failed; the server would not
start, saying it could not connect to port 5432.

I run McAfee Internet Security and the problem persisted even after opening
up 5432 in the firewall. However, to fix a separate problem I downloaded and
ran the workaround:

http://download.mcafee.com/products/licensed/cust_support_patches/mcprmusr.z
ip

to fix a problem with privacy service tool. After setting up and running
this tool on the postgres account the install went fine and I was able to
log into the system.

A couple of other differences I noticed - the automatically created account
was appreaing as .\postgres; my manually created account as postgres. I also
used different passwords for the successful install for the service and the
admin accounts.

Hope this is of some use to someone.

---(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