Обсуждение: CURRENT CVS: MULTIBYTE: CANT CONNECT....

Поиск
Список
Период
Сортировка

CURRENT CVS: MULTIBYTE: CANT CONNECT....

От
Larry Rosenman
Дата:
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

Re: CURRENT CVS: MULTIBYTE: CANT CONNECT....

От
Larry Rosenman
Дата:
* 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

Re: CURRENT CVS: MULTIBYTE: CANT CONNECT....

От
Karel Zak
Дата:
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

Re: CURRENT CVS: MULTIBYTE: CANT CONNECT....

От
Karel Zak
Дата:
> 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

Re: CURRENT CVS: MULTIBYTE: CANT CONNECT....

От
Bruce Momjian
Дата:
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

Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT....

От
Tatsuo Ishii
Дата:
> > > > 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

Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT....

От
Bruce Momjian
Дата:
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

Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT....

От
Larry Rosenman
Дата:
* 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

Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT....

От
Tatsuo Ishii
Дата:
> 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

Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT....

От
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

Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT....

От
Karel Zak
Дата:
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

Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT....

От
Tatsuo Ishii
Дата:
> > 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

Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT....

От
Karel Zak
Дата:
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

Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT....

От
Tatsuo Ishii
Дата:
> > 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

Чтобы сделать работу с сайтом удобнее, мы используем cookie и аналитический сервис «Яндекс.Метрика». Продолжая пользоваться сайтом, вы соглашаетесь с их использованием.