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 



Fri, 19 Nov 1999 10:19:49 +0000
"Oliver Elphick" <olly@lfix.co.uk>
Problems in 6.5.3 with Multi-Byte encoding
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


Fri, 19 Nov 1999 14:19:00 +0300 (MSK)
Oleg Bartunov <oleg@sai.msu.su>
Re: [BUGS] Problems in 6.5.3 with Multi-Byte encoding
> 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

Sat, 20 Nov 1999 21:05:26 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] Re: [BUGS] Problems in 6.5.3 with Multi-Byte encoding 

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

Mon, 29 Nov 1999 22:17:28 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Problems in 6.5.3 with Multi-Byte encoding
> 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



Tue, 30 Nov 1999 13:43:27 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] Problems in 6.5.3 with Multi-Byte encoding