Thread: 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
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
> I have another kind of problem related with MB and 6.5.3. > > On FreeBSD 3.1: [snip] > 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). I think no change has been made between 6.5.2 and 6.5.3 regarding MB. Can you send me the KOI8 data and WIN data that is supposed to be correct? I will check it out on a FreeBSD 3.2 machine. > > With PostgreSQL compiled with support for locales and multi-byte encoding: > > > > initdb -e BIG5 No, you cannot do this. If you want to use traditional Chinese, you have to make a database with EUC_TW (initdb -e EUC_TW) then set the PGCLIENTENCODING environment variable to BIG5 on the client side. See doc/README.mb for more details. Maybe initdb should reject BIG5. I will do it in for the next release. --- Tatsuo Ishii
Anyone want to comment on this? BIG5 anyone? > 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 > > > > ************ > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> Anyone want to comment on this? BIG5 anyone? > > > 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 The answer is: You should not do initdb with BIG5, instead you could do: initdb -e EUC_TW BIG5 and EUC_TW are both for traditional Chinese, only EUC_TW can be used for the proffered encoding for the backend, however. In the setting above, you could use EUC_TW for the frontend side and BIG5 as well. To use BIG5 in the fronend, you set the environment variable PGCLIENTENCODING to "BIG5" if you use psql or applications those are using libpq. In this case, an automatic code conversion between BIG5 and EUC_TW will be performed in the backend. I'll add the code to prevent BIG5 for initdb -e in the next release. -- Tatsuo Ishii