Обсуждение: restored database locale problem

Hi folks.

I've just FUBAR'd one of my databases so I dropped it and and then recreated
it from a pg_dump taken at 1am today.

Everything went fine with no errors or warning while recreating everything,
but now one of my selects doesn't work.  A quick google and scan of the
postgresql hasn't helped. My other databases within the same server are all
working fine.

Gary

goole=# select r_id as key, * from new_request_details where
(upper(r_registration) like upper('%D55D4473%') or  upper(r_chassis) like
upper('%D55D4473%') or  upper(r_pack_mats) like upper('%D55D4473%') or
upper(c_des) like upper('%D55D4473%') ) order by r_delivery,  r_delivery,
r_created
goole-# ;
ERROR:  invalid multibyte character for locale
HINT:  The server's LC_CTYPE locale is probably incompatible with the database
encoding.
goole=#
--
Gary Stainburn

This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000

Gary Stainburn <gary.stainburn@ringways.co.uk> writes:
> ERROR:  invalid multibyte character for locale
> HINT:  The server's LC_CTYPE locale is probably incompatible with the database encoding.

The HINT seems straightforward enough to me ;-).  What do "show
lc_ctype" and "show server_encoding" say?

            regards, tom lane

On Wednesday 28 December 2005 15:58, Tom Lane wrote:
> Gary Stainburn <gary.stainburn@ringways.co.uk> writes:
> > ERROR:  invalid multibyte character for locale
> > HINT:  The server's LC_CTYPE locale is probably incompatible with the
> > database encoding.
>
> The HINT seems straightforward enough to me ;-).  What do "show
> lc_ctype" and "show server_encoding" say?
>
>             regards, tom lane

goole=# show lc_ctype;
  lc_ctype
-------------
 en_US.UTF-8
(1 row)

goole=# show server_encoding;
 server_encoding
-----------------
 UNICODE
(1 row)

goole=#

The documentation I read all related to installing and configuring the server.
This has arisen from reading back into an existing server config a pg_dump
that was taken from the same server.

Gary
--
Gary Stainburn

This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000

Gary Stainburn <gary.stainburn@ringways.co.uk> writes:
> goole=# show lc_ctype;
>   lc_ctype
> -------------
>  en_US.UTF-8
> (1 row)

> goole=# show server_encoding;
>  server_encoding
> -----------------
>  UNICODE
> (1 row)

Hm.  Well, the error message implies that there's some data in the
database that we think is valid but mbstowcs() doesn't agree.  If this
is a pre-8.1 release then you could be getting burnt by the bugs we
previously had with more-than-two-byte UTF8 sequences.

> This has arisen from reading back into an existing server config a pg_dump
> that was taken from the same server.

Do you see the error if you just EXPLAIN the problem query, without
executing it?  If so, the failure is probably happening because a bogus
data value happens to show up in the pg_stats statistics for one of the
columns used in the query.  Since these entries come from a random
sample, re-ANALYZE-ing the table will probably make the EXPLAIN error
come and go.  Which leaves you needing to grovel through the whole table
to find the bad data :-(

            regards, tom lane

On Wednesday 28 December 2005 16:22, Tom Lane wrote:
> Gary Stainburn <gary.stainburn@ringways.co.uk> writes:
> > goole=# show lc_ctype;
> >   lc_ctype
> > -------------
> >  en_US.UTF-8
> > (1 row)
> >
> > goole=# show server_encoding;
> >  server_encoding
> > -----------------
> >  UNICODE
> > (1 row)
>
> Hm.  Well, the error message implies that there's some data in the
> database that we think is valid but mbstowcs() doesn't agree.  If this
> is a pre-8.1 release then you could be getting burnt by the bugs we
> previously had with more-than-two-byte UTF8 sequences.

I'm using the Fedora 4 RPMs version 8.0.4-2. 8.0.5-1 are the latest, which I'm
going to upgrade to using yum.

>
> > This has arisen from reading back into an existing server config a
> > pg_dump that was taken from the same server.
>
> Do you see the error if you just EXPLAIN the problem query, without
> executing it?

Running explain does not generate any errors.

> If so, the failure is probably happening because a bogus
> data value happens to show up in the pg_stats statistics for one of the
> columns used in the query.  Since these entries come from a random
> sample, re-ANALYZE-ing the table will probably make the EXPLAIN error
> come and go.  Which leaves you needing to grovel through the whole table
> to find the bad data :-(
>
>             regards, tom lane

analyze requests;

seems to have fixed it.  Thanks.

Gary
--
Gary Stainburn

This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000