Thread: CURRENT CVS: MULTIBYTE: CANT CONNECT....
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 -- 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
* 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