Обсуждение: 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.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...
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
"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