"Walter Cruz" <[EMAIL PROTECTED]> writes:
> My initdb was:
> initdb -E LATIN1 --locale=pt_BR
> By that initdb, the $LANG of the system was pt_BR.UTF-8 .
> A simple query that shows the problem:
> select true AS
> "áaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
OK, I was able to reproduce this here:
postgres=# select true AS
"áaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
;
ERROR: invalid string enlargement request size 1073741823
What is happening is that vsnprintf() is failing because it doesn't like
its input data. elog.c's EVALUATE_MESSAGE macro thinks that the only
possible reason for failure is that the output buffer isn't large
enough, so it enlarges and tries again, leading soon to the palloc error
displayed above.
Possibly we should put some effort into producing a more useful error
message here, but I'm reluctant to fool with it, because our historical
experience is that vsnprintf's behavior just isn't very consistent
across platforms.
In any case, the bottom-line reason why you're having a problem is that
the database encoding (LATIN1) is inconsistent with the encoding
specified by the server's locale (UTF-8), thus allowing vsnprintf to see
what it thinks is bad data.
PG 8.3 contains defenses to prevent that sort of inconsistency, and
I think that's probably all we need to do about this.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
