Re: ERROR: invalid memory alloc request size

Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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