invalid memory alloc request size
Linux 2.4.23 on AMD 450MHz.
pgsql 7.4.1
configure --enable-multibyte=UNICODE
locale is zh_TW.Big5
IIRC, when I did "initdb -E UNICODE" or "createdb db1", I
saw the following message from pgsql:
...locale "C"...
The problem:
db1=# select distinct * from t53 where f1='J200312014' order
by 1;
f0 | f1 | f3 | f4 | f5 | f6 | f7 | f8
| f9 | f10 | f11 | f12 | f99
----+------------+-----------+----+-----+-------+-------+---
-+----+----------+-----+-----+-----
1 | J200312014 | 1101 | D | USD | 200 | 6930 | 1
| A | | | | rps
1 | J200312014 | 1101-1 | D | USD | 100 | 3500 | 1
| D | | | | rps
1 | J200312014 | 1102-A012 | D | TWD | 10000 | 10000 | 1
| B | savings1 | | | rps
1 | J200312014 | 1108 | D | TWD | 100 | 100 | 1
| C | bill2 | | | rps
1 | J200312014 | 1110 | C | USD | 600 | 20790 | 1
| r | s1 | | | rps
1 | J200312014 | 2210-1 | C | USD | 500 | 17325 | 1
| T | | | | rps
(6 rows)
db1=# select distinct * into x53 from t53 where
f1='J200312014' order by 1;
SELECT
db1=# show client_encoding;
client_encoding
-----------------
unicode
(1 row)
db1=# select * from x53;
f0 | f1 | f3 | f4 | f5 | f6 | f7 | f8
| f9 | f10 | f11 | f12 | f99
----+------------+-----------+----+-----+-------+-------+---
-+----+----------+-----+-------+-----
1 | J200312014 | 1101 | D | USD | 200 | 6930 | 1
| | rps | | |
1 | J200312014 | 1101 | D | USD | 200 | 6930 | 1
| A | rps | | |
1 | J200312014 | 1101-1 | D | USD | 100 | 3500 | 1
| | | rps | |
1 | J200312014 | 1101-1 | D | USD | 100 | 3500 | 1
| D | | rps | |
1 | J200312014 | 1102-A012 | D | TWD | 10000 | 10000 | 1
| | savings1 | rps | |
1 | J200312014 | 1102-A012 | D | TWD | 10000 | 10000 | 1
| B | savings1 | rps | |
1 | J200312014 | 1108 | D | TWD | 100 | 100 | 1
| | | | bill2 |
1 | J200312014 | 1108 | D | TWD | 100 | 100 | 1
| C | | | bill2 |
1 | J200312014 | 1110 | C | USD | 600 | 20790 | 1
| | s1 | | rps |
1 | J200312014 | 2210-1 | C | USD | 500 | 17325 | 1
| T | rps | | |
1 | J200312014 | 2210-1 | C | USD | 500 | 17325 | 1
| | | rps | |
(11 rows)
db1=# drop table x53;
DROP TABLE
db1=# select distinct * into x53 from t53 where
f1='J200312014' order by 1;
SELECT
db1=# select * from x53;
ERROR: invalid memory alloc request size 4294967293
db1=# select 4294967293>>16;
?column?
----------
65535
(1 row)
"cnliou" <cnliou@so-net.net.tw> writes:
Linux 2.4.23 on AMD 450MHz.
pgsql 7.4.1
configure --enable-multibyte=UNICODE
locale is zh_TW.Big5
IIRC, when I did "initdb -E UNICODE" or "createdb db1", I
saw the following message from pgsql:
...locale "C"...
Uh ... you're being self-contradictory about the locale setting.
Please show us the result of "show lc_collate" and "show lc_ctype"
just to remove doubt.
Also, it's hard to reproduce your example when we don't know the
data types of the table columns...
regards, tom lane
Tom, Thank you very much!
configure --enable-multibyte=UNICODE
locale is zh_TW.Big5IIRC, when I did "initdb -E UNICODE" or "createdb db1", I
saw the following message from pgsql:
...locale "C"...Uh ... you're being self-contradictory about the locale
setting.
Please show us the result of "show lc_collate" and "show
lc_ctype"
just to remove doubt.
Also, it's hard to reproduce your example when we don't
know the
data types of the table columns...
db1=# show lc_collate;
lc_collate
------------
C
(1 row)
db1=# show lc_ctype;
lc_ctype
----------
C
(1 row)
db1=# \d x53
Table "public.x53"
Column | Type | Modifiers
--------+-----------------------+-----------
f0 | character varying(20) |
f1 | character varying(20) |
f3 | character varying(20) |
f4 | "char" |
f5 | character(3) |
f6 | numeric |
f7 | numeric |
f8 | character varying(20) |
f9 | "char" |
f10 | character varying(80) |
f11 | character varying(20) |
f12 | character varying(20) |
f99 | character varying(20) |
Can contradictory locale settings produce completely wrong
SELECT result in addition to server's death (it happened
once)?
Regards,
CN
Import Notes
Resolved by subject fallback
"cnliou" <cnliou@so-net.net.tw> writes:
[ bizarre results from SELECT INTO ]
I had an idea: was the original table (t53) created WITHOUT OIDS?
There's a post-7.4.1 bug fix involving doing SELECT INTO from a table
without oids. I'm not certain this explains your problem, but I'm
not having any luck reproducing the behavior on my current 7.4 build.
regards, tom lane
[ bizarre results from SELECT INTO ]
I had an idea: was the original table (t53) created WITHOUT
OIDS?
That exactly is what I did.
There's a post-7.4.1 bug fix involving doing SELECT INTO
from a table
without oids. I'm not certain this explains your problem,
but I'm
not having any luck reproducing the behavior on my current
7.4 build.
It explains my problem. Thank you again!
Best Regards,
CN
Import Notes
Resolved by subject fallback