Thread

  1. Problems in 6.5.3 with Multi-Byte encoding

    Oliver Elphick <olly@lfix.co.uk> — 1999-11-19T10:19:49Z

    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 
    
    
    
    
  2. Re: [BUGS] Problems in 6.5.3 with Multi-Byte encoding

    Oleg Bartunov <oleg@sai.msu.su> — 1999-11-19T11:19:00Z

    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
    
    
    
  3. Re: [HACKERS] Problems in 6.5.3 with Multi-Byte encoding

    Bruce Momjian <pgman@candle.pha.pa.us> — 1999-11-30T03:17:28Z

    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
    
    
  4. Re: [HACKERS] Problems in 6.5.3 with Multi-Byte encoding

    Tatsuo Ishii <t-ishii@sra.co.jp> — 1999-11-30T04:43:27Z

    > 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