On Wednesday 28 December 2005 16:22, Tom Lane wrote:
> Gary Stainburn <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
