Michael Arnold <myk321@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
