Re: [BUGS] Problems in 6.5.3 with Multi-Byte encoding - Mailing list pgsql-bugs
| From | Oleg Bartunov |
|---|---|
| Subject | Re: [BUGS] Problems in 6.5.3 with Multi-Byte encoding |
| Date | |
| Msg-id | Pine.GSO.3.96.SK.991119140800.3910s-100000@ra Whole thread Raw |
| In response to | Problems in 6.5.3 with Multi-Byte encoding ("Oliver Elphick" <olly@lfix.co.uk>) |
| Responses |
Re: [HACKERS] Re: [BUGS] Problems in 6.5.3 with Multi-Byte encoding
|
| List | pgsql-bugs |
I have another kind of problem related with MB and 6.5.3.
On FreeBSD 3.1:
nature=> select u_address from users;
u_address
------------------------------
Москва, Университетский пр. 13
(1 row)
nature=> set client_encoding to 'WIN';
SET VARIABLE
nature=> select u_address from users;
u_address
------------------------------
mOSKWA, uNIWERSITETSKIJ PR. 13
(1 row)
It seems that 8-bit was stripped !
I've checked locale on this machine - it works.
Moreover, 8-bit stripped even if I do silly setting of client_encoding
to native encoding:
ature=> set client_encoding to 'KOI8';
SET VARIABLE
nature=> select u_address from users;
u_address
------------------------------
mOSKWA, uNIWERSITETSKIJ PR. 13
(1 row)
It's interesting that on Linux I have no problem.
I have no time right now to test 6.5.2 but I recall I had no
such problem (not 100% sure).
Regards,
Oleg
On Fri, 19 Nov 1999, Oliver Elphick wrote:
> Date: Fri, 19 Nov 1999 10:19:49 +0000
> From: Oliver Elphick <olly@lfix.co.uk>
> To: pgsql-bugs@postgresql.org, pgsql-hackers@postgresql.org
> Cc: 50388@bugs.debian.org
> Subject: [BUGS] Problems in 6.5.3 with Multi-Byte encoding
>
> With PostgreSQL compiled with support for locales and multi-byte encoding:
>
> initdb -e BIG5
>
> [start postmaster]
> psql template1
> \dS causes a segmentation fault in the backend
>
> >From the log:
>
> StartTransactionCommand
> query: SELECT usename, relname, relkind, relhasrules FROM pg_class, pg_user
> WHERE usesysid = relowner and ( relkind = 'r' OR relkind = 'i' OR relkind =
> 'S') and relname ~ '^pg_' and (relkind != 'i' OR relname !~ '^xinx') ORDER BY
> relname
> ProcessQuery
> /usr/lib/postgresql/bin/postmaster: reaping dead processes...
> /usr/lib/postgresql/bin/postmaster: CleanupProc: pid 294 exited with status 11
>
>
> This can be isolated to the pattern-matching operator:
>
> template1=> select * from pg_class where relname ~ '^pg_' ;
> pqReadData() -- backend closed the channel unexpectedly.
>
> ------- Forwarded Message
>
> Date: Thu, 18 Nov 1999 19:48:39 +0800
> From: Chuan-kai Lin <cklin@oink.cc.ntu.edu.tw>
> To: Oliver Elphick <olly@lfix.co.uk>
> Subject: Re: Bug#50388: Backend close client-server channel unexpectedly
>
> On Thu, Nov 18, 1999 at 09:18:34AM +0000, Oliver Elphick wrote:
> > Something must have happened to the database as it was being created.
> > At the moment, I would put it down to cosmic rays or something.
>
> Through a friend who specializes in metaphysics and astronomy, I
> have traced down the exact cause of our problem: PostgreSQL does
> not like BIG5 encoding. If you supply "-e BIG5" to initdb, the
> resulting database will be hosed. Plain and simple.
>
> This looks like a tough one... somebody better notify the upstream
> developers about this.
>
> - -- Chuan-kai Lin
>
>
> ------- End of Forwarded Message
>
>
> --
> Vote against SPAM: http://www.politik-digital.de/spam/
> ========================================
> Oliver Elphick Oliver.Elphick@lfix.co.uk
> Isle of Wight http://www.lfix.co.uk/oliver
> PGP key from public servers; key ID 32B8FAA1
> ========================================
> "To show forth thy lovingkindness in the morning, and
> thy faithfulness every night." Psalms 92:2
>
>
>
> ************
>
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
pgsql-bugs by date: