Thread: Re: [HACKERS] CURRENT CVS: MULTIBYTE: CANT CONNECT....
> 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
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