| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gary Stainburn <gary(dot)stainburn(at)ringways(dot)co(dot)uk> |
| Cc: | pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: restored database locale problem |
| Date: | 2005-12-28 16:22:06 |
| Message-ID: | 17656.1135786926@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Gary Stainburn <gary(dot)stainburn(at)ringways(dot)co(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gary Stainburn | 2005-12-28 17:39:00 | Re: restored database locale problem |
| Previous Message | Gary Stainburn | 2005-12-28 16:07:30 | Re: restored database locale problem |