Michael Arnold <myk321@gmail.com> writes:
> The locale is the same on both machines: "en_SG.UTF-8"
> I've extracted the smallest set of code which still produces the
> error. Unfortunately its still more than 1000 lines of code, as
> without the thread and connection pools the error goes away. If only
> 1 thread or only 1 connection is used the error also goes away.
Hm. I ran this several times on a Fedora 16 box with locale en_SG.utf8,
and didn't see any assertion failures. I did see a fair amount of
ERROR: invalid byte sequence for encoding "UTF8": 0xf0 0x66 0x02
STATEMENT: INSERT INTO TABLE1( FIELD1, FIELD2, FIELD3, FIELD4) VALUES( $1, $2, $3, $4);
with varying specific data being complained of. Some investigation
disclosed the reason for that --- the test program is setting up the
strings to be inserted like this:
strncpy(DataFileInfo->Field1, "AAA", 3);
strncpy(DataFileInfo->Field2, "BBB", 3);
which of course fails to copy any trailing \0 into the struct, so unless
the struct happens to contain zeroes to start with (which is likely but
not guaranteed for a freshly-malloced block), you get strings that
appear to contain platform-specific garbage. Changing the lengths to
"4" made the encoding complaints go away.
So at this point I surmise that the issue is triggered by unexpected
non-ASCII data, but it's going to be unlikely that anybody else can
reproduce it on the basis of this example. Also, this bug in your
test case may or may not have much to do with the original problem...
regards, tom lane
