CURRENT CVS: MULTIBYTE: CANT CONNECT....

* Larry Rosenman <ler@lerctr.org> [010907 21:06]:

I finally got all the way through a compile set:

CC=cc CXX=CC ./configure --prefix=/usr/local/pgsql --enable-syslog \
--with-CXX --with-perl --enable-multibyte --enable-cassert \
--with-includes=/usr/local/include --with-libs=/usr/local/lib \
--enable-debug \
--with-tcl --with-tclconfig=/usr/local/lib \
--with-tkconfig=/usr/local/lib --enable-locale
and when I try to connect to an existing DB, loaded from a pg_dump
from the previous 7.2devel sources, I get:
TRAP: Failed Assertion("!(ClientEncoding):", File: "mbutils.c", Line:
314)
!(ClientEncoding) (0) [No such file or directory]
DEBUG: server process (pid 3077) was terminated by signal 6
DEBUG: terminating any other active server processes
DEBUG: all server processes terminated; reinitializing shared memory
and semaphores
DEBUG: database system was interrupted at 2001-09-07 21:00:33 CDT
DEBUG: checkpoint record is at 0/2922408
DEBUG: redo record is at 0/2922408; undo record is at 0/0; shutdown
TRUE
DEBUG: next transaction id: 824; next oid: 371237
DEBUG: database system was not properly shut down; automatic recovery
in progress
DEBUG: ReadRecord: record with zero length at 0/2922448
DEBUG: redo is not required
DEBUG: database system is ready

THIS IS UNACCEPTABLE.

How do I get out of it?

LER

The following patch fixes it:

Index: mbutils.c
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/mb/mbutils.c,v
retrieving revision 1.20
diff -c -r1.20 mbutils.c
*** mbutils.c	2001/09/06 04:57:29	1.20
--- mbutils.c	2001/09/08 02:11:55
***************
*** 21,27 ****
   *
   * Karel Zak (Aug 2001)
   */
! static pg_enc2name	*ClientEncoding = NULL;
  static pg_enc2name	*DatabaseEncoding = &pg_enc2name_tbl[ PG_SQL_ASCII ];

  static void	(*client_to_mic) ();	/* something to MIC */
--- 21,27 ----
   *
   * Karel Zak (Aug 2001)
   */
! static pg_enc2name	*ClientEncoding = &pg_enc2name_tbl[ PG_SQL_ASCII ];
  static pg_enc2name	*DatabaseEncoding = &pg_enc2name_tbl[ PG_SQL_ASCII ];

static void (*client_to_mic) (); /* something to MIC */
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

On Fri, Sep 07, 2001 at 09:06:18PM -0500, Larry Rosenman wrote:

I finally got all the way through a compile set:

CC=cc CXX=CC ./configure --prefix=/usr/local/pgsql --enable-syslog \
--with-CXX --with-perl --enable-multibyte --enable-cassert \
--with-includes=/usr/local/include --with-libs=/usr/local/lib \
--enable-debug \
--with-tcl --with-tclconfig=/usr/local/lib \
--with-tkconfig=/usr/local/lib --enable-locale
and when I try to connect to an existing DB, loaded from a pg_dump
from the previous 7.2devel sources, I get:
TRAP: Failed Assertion("!(ClientEncoding):", File: "mbutils.c", Line:
314)
!(ClientEncoding) (0) [No such file or directory]

Interesting. I don't know why, but someting don't call
pg_set_client_encoding() before usage encoding routines (maybe
libpq don't set client encoding if it's default SQL_ASCII, but
I'm almost sure that I check this case).

A simple and robus solution is in the begin of mbutils.c set default
ClientEncoding to SQL_ASCII (like default DatabaseEncoding). Bruce, can
you change it? It's one line change. Again thanks.

Karel

--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/

C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

On Sat, Sep 08, 2001 at 10:29:38AM +0200, Karel Zak wrote:

On Fri, Sep 07, 2001 at 09:06:18PM -0500, Larry Rosenman wrote:

I finally got all the way through a compile set:

CC=cc CXX=CC ./configure --prefix=/usr/local/pgsql --enable-syslog \
--with-CXX --with-perl --enable-multibyte --enable-cassert \
--with-includes=/usr/local/include --with-libs=/usr/local/lib \
--enable-debug \
--with-tcl --with-tclconfig=/usr/local/lib \
--with-tkconfig=/usr/local/lib --enable-locale
and when I try to connect to an existing DB, loaded from a pg_dump
from the previous 7.2devel sources, I get:
TRAP: Failed Assertion("!(ClientEncoding):", File: "mbutils.c", Line:
314)
!(ClientEncoding) (0) [No such file or directory]

Interesting. I don't know why, but someting don't call
pg_set_client_encoding() before usage encoding routines (maybe
libpq don't set client encoding if it's default SQL_ASCII, but
I'm almost sure that I check this case).

A simple and robus solution is in the begin of mbutils.c set default
ClientEncoding to SQL_ASCII (like default DatabaseEncoding). Bruce, can
you change it? It's one line change. Again thanks.

Forget it! A default client encoding must be set by actual database encoding...
Please apply the small attached patch that solve it better.

I check and test it with attached patch and it works correct:

test=# SHOW CLIENT_ENCODING;
NOTICE: Current client encoding is SQL_ASCII
SHOW VARIABLE
test=# SHOW SERVER_ENCODING;
NOTICE: Current server encoding is SQL_ASCII
SHOW VARIABLE
test=# CREATE DATABASE l2 WITH ENCODING='ISO-8859-2';
CREATE DATABASE
test=# \c l2
You are now connected to database l2.
l2=# \l
List of databases
Name | Owner | Encoding
-----------+----------+-----------
l2 | zakkr | LATIN2
template0 | postgres | SQL_ASCII
template1 | postgres | SQL_ASCII
test | postgres | SQL_ASCII
(4 rows)

l2=# SHOW SERVER_ENCODING;
NOTICE: Current server encoding is LATIN2
SHOW VARIABLE
l2=# SHOW CLIENT_ENCODING;
NOTICE: Current client encoding is LATIN2
SHOW VARIABLE
l2=#

Larry, wait when Bruce apply this small change and try previous
examples.

Karel

--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/

C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

Patch applied. Thanks.

On Sat, Sep 08, 2001 at 10:29:38AM +0200, Karel Zak wrote:

On Fri, Sep 07, 2001 at 09:06:18PM -0500, Larry Rosenman wrote:

I finally got all the way through a compile set:

CC=cc CXX=CC ./configure --prefix=/usr/local/pgsql --enable-syslog \
--with-CXX --with-perl --enable-multibyte --enable-cassert \
--with-includes=/usr/local/include --with-libs=/usr/local/lib \
--enable-debug \
--with-tcl --with-tclconfig=/usr/local/lib \
--with-tkconfig=/usr/local/lib --enable-locale
and when I try to connect to an existing DB, loaded from a pg_dump
from the previous 7.2devel sources, I get:
TRAP: Failed Assertion("!(ClientEncoding):", File: "mbutils.c", Line:
314)
!(ClientEncoding) (0) [No such file or directory]

Interesting. I don't know why, but someting don't call
pg_set_client_encoding() before usage encoding routines (maybe
libpq don't set client encoding if it's default SQL_ASCII, but
I'm almost sure that I check this case).

A simple and robus solution is in the begin of mbutils.c set default
ClientEncoding to SQL_ASCII (like default DatabaseEncoding). Bruce, can
you change it? It's one line change. Again thanks.

Forget it! A default client encoding must be set by actual database encoding...
Please apply the small attached patch that solve it better.

I check and test it with attached patch and it works correct:

test=# SHOW CLIENT_ENCODING;
NOTICE: Current client encoding is SQL_ASCII
SHOW VARIABLE
test=# SHOW SERVER_ENCODING;
NOTICE: Current server encoding is SQL_ASCII
SHOW VARIABLE
test=# CREATE DATABASE l2 WITH ENCODING='ISO-8859-2';
CREATE DATABASE
test=# \c l2
You are now connected to database l2.
l2=# \l
List of databases
Name | Owner | Encoding
-----------+----------+-----------
l2 | zakkr | LATIN2
template0 | postgres | SQL_ASCII
template1 | postgres | SQL_ASCII
test | postgres | SQL_ASCII
(4 rows)

l2=# SHOW SERVER_ENCODING;
NOTICE: Current server encoding is LATIN2
SHOW VARIABLE
l2=# SHOW CLIENT_ENCODING;
NOTICE: Current client encoding is LATIN2
SHOW VARIABLE
l2=#

Larry, wait when Bruce apply this small change and try previous
examples.

Karel

--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/

C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

[ Attachment, skipping... ]

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@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

CC=cc CXX=CC ./configure --prefix=/usr/local/pgsql --enable-syslog \
--with-CXX --with-perl --enable-multibyte --enable-cassert \
--with-includes=/usr/local/include --with-libs=/usr/local/lib \
--enable-debug \
--with-tcl --with-tclconfig=/usr/local/lib \
--with-tkconfig=/usr/local/lib --enable-locale
and when I try to connect to an existing DB, loaded from a pg_dump
from the previous 7.2devel sources, I get:
TRAP: Failed Assertion("!(ClientEncoding):", File: "mbutils.c", Line:
314)
!(ClientEncoding) (0) [No such file or directory]

Interesting. I don't know why, but someting don't call
pg_set_client_encoding() before usage encoding routines (maybe
libpq don't set client encoding if it's default SQL_ASCII, but
I'm almost sure that I check this case).

A simple and robus solution is in the begin of mbutils.c set default
ClientEncoding to SQL_ASCII (like default DatabaseEncoding). Bruce, can
you change it? It's one line change. Again thanks.

Karel,

The bug Larry reported seems for such a case of connecting non
existent database. The backend tries to send the error message to the
frontend using pg_server_to_client WITHOUT getting an encoding info
from the database. To fix this Larry's patch or you stat in the
previous mail are sufficient. I will commit the fix.

Forget it! A default client encoding must be set by actual database encoding...

Why? set_default_client_encoding does the job anyway.
--
Tatsuo Ishii

Tatsuo, I applied this patch. Please fix as needed.

CC=cc CXX=CC ./configure --prefix=/usr/local/pgsql --enable-syslog \
--with-CXX --with-perl --enable-multibyte --enable-cassert \
--with-includes=/usr/local/include --with-libs=/usr/local/lib \
--enable-debug \
--with-tcl --with-tclconfig=/usr/local/lib \
--with-tkconfig=/usr/local/lib --enable-locale
and when I try to connect to an existing DB, loaded from a pg_dump
from the previous 7.2devel sources, I get:
TRAP: Failed Assertion("!(ClientEncoding):", File: "mbutils.c", Line:
314)
!(ClientEncoding) (0) [No such file or directory]

Interesting. I don't know why, but someting don't call
pg_set_client_encoding() before usage encoding routines (maybe
libpq don't set client encoding if it's default SQL_ASCII, but
I'm almost sure that I check this case).

A simple and robus solution is in the begin of mbutils.c set default
ClientEncoding to SQL_ASCII (like default DatabaseEncoding). Bruce, can
you change it? It's one line change. Again thanks.

Karel,

The bug Larry reported seems for such a case of connecting non
existent database. The backend tries to send the error message to the
frontend using pg_server_to_client WITHOUT getting an encoding info
from the database. To fix this Larry's patch or you stat in the
previous mail are sufficient. I will commit the fix.

Forget it! A default client encoding must be set by actual database encoding...

Why? set_default_client_encoding does the job anyway.
--
Tatsuo Ishii

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@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

* Tatsuo Ishii <t-ishii@sra.co.jp> [010908 10:02]:

CC=cc CXX=CC ./configure --prefix=/usr/local/pgsql --enable-syslog \
--with-CXX --with-perl --enable-multibyte --enable-cassert \
--with-includes=/usr/local/include --with-libs=/usr/local/lib \
--enable-debug \
--with-tcl --with-tclconfig=/usr/local/lib \
--with-tkconfig=/usr/local/lib --enable-locale
and when I try to connect to an existing DB, loaded from a pg_dump
from the previous 7.2devel sources, I get:
TRAP: Failed Assertion("!(ClientEncoding):", File: "mbutils.c", Line:
314)
!(ClientEncoding) (0) [No such file or directory]

Interesting. I don't know why, but someting don't call
pg_set_client_encoding() before usage encoding routines (maybe
libpq don't set client encoding if it's default SQL_ASCII, but
I'm almost sure that I check this case).

A simple and robus solution is in the begin of mbutils.c set default
ClientEncoding to SQL_ASCII (like default DatabaseEncoding). Bruce, can
you change it? It's one line change. Again thanks.

Karel,

The bug Larry reported seems for such a case of connecting non
existent database. The backend tries to send the error message to the
frontend using pg_server_to_client WITHOUT getting an encoding info
from the database. To fix this Larry's patch or you stat in the
previous mail are sufficient. I will commit the fix.

I use password authentication, and that seems to be what tripped it.

The applied patch works for me.

Thanks, Gentlemen.

LER

Forget it! A default client encoding must be set by actual database encoding...

Why? set_default_client_encoding does the job anyway.
--
Tatsuo Ishii

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Tatsuo, I applied this patch. Please fix as needed.

Sure. I have come back from the business trip. I will take care of
this.
--
Tatsuo Ishii

Karel,

The bug Larry reported seems for such a case of connecting non
existent database. The backend tries to send the error message to the
frontend using pg_server_to_client WITHOUT getting an encoding info
from the database. To fix this Larry's patch or you stat in the
previous mail are sufficient. I will commit the fix.

I use password authentication, and that seems to be what tripped it.

Oh I see.

The applied patch works for me.

Thanks, Gentlemen.

You are welcome.
--
Tatsuo Ishii

On Sat, Sep 08, 2001 at 11:51:24PM +0900, Tatsuo Ishii wrote:

CC=cc CXX=CC ./configure --prefix=/usr/local/pgsql --enable-syslog \
--with-CXX --with-perl --enable-multibyte --enable-cassert \
--with-includes=/usr/local/include --with-libs=/usr/local/lib \
--enable-debug \
--with-tcl --with-tclconfig=/usr/local/lib \
--with-tkconfig=/usr/local/lib --enable-locale
and when I try to connect to an existing DB, loaded from a pg_dump
from the previous 7.2devel sources, I get:
TRAP: Failed Assertion("!(ClientEncoding):", File: "mbutils.c", Line:
314)
!(ClientEncoding) (0) [No such file or directory]

Interesting. I don't know why, but someting don't call
pg_set_client_encoding() before usage encoding routines (maybe
libpq don't set client encoding if it's default SQL_ASCII, but
I'm almost sure that I check this case).

A simple and robus solution is in the begin of mbutils.c set default
ClientEncoding to SQL_ASCII (like default DatabaseEncoding). Bruce, can
you change it? It's one line change. Again thanks.

Karel,

The bug Larry reported seems for such a case of connecting non
existent database. The backend tries to send the error message to the
frontend using pg_server_to_client WITHOUT getting an encoding info
from the database. To fix this Larry's patch or you stat in the
previous mail are sufficient. I will commit the fix.

Forget it! A default client encoding must be set by actual database encoding...

Why? set_default_client_encoding does the job anyway.

Here can't be used static default encoding as for DatabaseEncoding, because
typical code is

if (!ClientEncoding)
/* ...means "if user doesn't set itself client
* encoding by SET command"
*/
ClientEncoding = DatabaseEncoding;

and if you set anywhere before this as default
ClientEncoding = &pg_enc2name_tbl[ PG_SQL_ASCII ]; the ClientEncoding will
always TRUE and always SQL_ASCII and the only way is change it by 'SET
CLIENT_ENCODING' command. But we don't want it, wanted is after connection
set as default ClientEncoding same encoding as actual DabaseEncoding.

Karel

--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/

C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

Why? set_default_client_encoding does the job anyway.

Here can't be used static default encoding as for DatabaseEncoding, because
typical code is

if (!ClientEncoding)
/* ...means "if user doesn't set itself client
* encoding by SET command"
*/
ClientEncoding = DatabaseEncoding;

and if you set anywhere before this as default
ClientEncoding = &pg_enc2name_tbl[ PG_SQL_ASCII ]; the ClientEncoding will
always TRUE and always SQL_ASCII and the only way is change it by 'SET
CLIENT_ENCODING' command. But we don't want it, wanted is after connection
set as default ClientEncoding same encoding as actual DabaseEncoding.

Don't worry about that. Before anything user could do, postgres's
start up procedure sets the appropreate encoding to ClientEncoding
variable.

Also please note that "wanted is after connection set as default
ClientEncoding same encoding as actual DabaseEncoding" is not
corrent. The ClientEncoding might be set differently if
PGCLIENTENCODING is set before postmaster starts up.
--
Tatsuo Ishii

On Mon, Sep 10, 2001 at 03:50:46PM +0900, Tatsuo Ishii wrote:

Don't worry about that. Before anything user could do, postgres's
start up procedure sets the appropreate encoding to ClientEncoding
variable.

Larry's backend knows method how call conversion routines, without
set ClientEncoding:-) IMHO with my patch is always sure that backend
never crash for this.

Also please note that "wanted is after connection set as default
ClientEncoding same encoding as actual DabaseEncoding" is not
corrent. The ClientEncoding might be set differently if
PGCLIENTENCODING is set before postmaster starts up.

You are right. I was mean "if PGCLIENTENCODING is not set".

Karel

--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/

C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

Don't worry about that. Before anything user could do, postgres's
start up procedure sets the appropreate encoding to ClientEncoding
variable.

Larry's backend knows method how call conversion routines, without
set ClientEncoding:-) IMHO with my patch is always sure that backend
never crash for this.

Looks like you are trying to protect yourself from the internal logic
bugs that should be found by Asserts or carefull debugging IMHO.
--
Tatsuo Ishii