Re: ERROR: invalid memory alloc request size

[Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>]

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