Re: [ADMIN] ERROR: invalid memory alloc request size

[Tom Lane]

Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Johann Spies wrote:
>> #3  0x00000000005ff1c8 in perform_default_encoding_conversion (
>> src=0x2b881e87f040 "\"2007-04-20\" \"18:07:06\" \"192.168.0.100\" \"73\" 
>> \"http://www.kerkbode.co.za/kerkbode/images/blank.gif\\\"\"\n\"2007-04-20\"; 
>> \"18:07:06\" \"192.168.0.100\" \"69\" 
>> \"http://develop.christians.co.za/phpAdsNew/adx.js\"\n\"20";..., 
>> len=337739539, is_client_to_server=5 '\005') at mbutils.c:461


> Interesting.  You are passing a single 300 MB string here, not
> 90-something char lines.  The problem is probably in newlines.  Why are
> they not getting used as line separators escapes me.

Stripped of gdb's own backslashing, the data seems to be 

        ...images/blank.gif\""
        "2007...

which leads me to think that the dump was generated on the assumption
that backslash is the escape character, but is being reloaded under a
different assumption.  Once you got out-of-sync on that one data value,
you'd have a mess --- all the intended line-ending newlines would be
inside quotes, up till you hit another URL with an embedded quote
(or newline?).  CSV is not exactly a robust representation :-(

So the short answer seems to be that we were all misled by the large
alloc-request number into thinking there was some data-corruption
behavior involved, when we should have been quizzing Johann on exactly
what COPY parameters he was giving.

                        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