Обсуждение: Invalid memory alloc request

On systems running Postgresql 8.3.6, I have a nightly backup using
pg_dump that failed on two machines overnight with this error:

pg_dump: SQL command failed
pg_dump: Error message from server: ERROR:  invalid memory alloc request size 1376006425
pg_dump: The command was: COPY public.tablename (ts, fn, data, textdata) TO stdout;

The two machines where this occurred have similar, but not identical,
data in this table.  Both machines are running FreeBSD 7.1 amd64.  I ran
a query "SELECT SUM(LENGTH(data)), SUM(LENGTH(textdata)) FROM tablename"
to sum the length of the data and textdata columns (both of type bytea)
in this table, and the results were around 140MB for the data column and
500MB for the textdata.

I have seen reports of "invalid memory alloc request" errors in the mail
list archives, but those were considered likely to be file corruption or
memory errors.  Since this happened simultaneously on two separate
machines, I would not expect these issues to be likely causes.

Any suggestions?

Thanks,
Guy Helmer

Guy Helmer <ghelmer@palisadesys.com> writes:
> On systems running Postgresql 8.3.6, I have a nightly backup using
> pg_dump that failed on two machines overnight with this error:

> pg_dump: SQL command failed
> pg_dump: Error message from server: ERROR:  invalid memory alloc request size 1376006425
> pg_dump: The command was: COPY public.tablename (ts, fn, data, textdata) TO stdout;

Normally I'd say "data corruption", but it is odd if you got the
identical message from two different machines.  Can you reproduce
it with a debugger attached?  If so, a backtrace from the call of
errfinish might be useful.

            regards, tom lane

Tom Lane wrote:

Guy Helmer <ghelmer@palisadesys.com> writes: 

On systems running Postgresql 8.3.6, I have a nightly backup using 
pg_dump that failed on two machines overnight with this error:   

pg_dump: SQL command failed
pg_dump: Error message from server: ERROR:  invalid memory alloc request size 1376006425
pg_dump: The command was: COPY public.tablename (ts, fn, data, textdata) TO stdout;   

Normally I'd say "data corruption", but it is odd if you got the
identical message from two different machines.  Can you reproduce
it with a debugger attached?  If so, a backtrace from the call of
errfinish might be useful.
		regards, tom lane 

Yes, here is the backtrace.

Thanks for any help!

#0  errfinish (dummy=0) at elog.c:322
#1  0x000000000070e605 in elog_finish (elevel=20,
    fmt=0x80f120 "invalid memory alloc request size %lu") at elog.c:971
#2  0x000000000072e9a6 in MemoryContextAlloc (context=0x802d2e250, size=1376006425)
    at mcxt.c:510                                                              
#3  0x00000000006bbbf4 in byteaout (fcinfo=0x7fffffffdaf0) at varlena.c:197    
#4  0x0000000000714692 in FunctionCall1 (flinfo=0x802ccff18, arg1=34395645151) at fmgr.c:1254
#5  0x0000000000715c45 in OutputFunctionCall (flinfo=0x802ccff18, val=34395645151)
    at fmgr.c:1887                                                             
#6  0x000000000051301c in CopyOneRowTo (cstate=0x802c4bc80, tupleOid=0, values=0x802c4bfb0,
    nulls=0x802cbf880 "") at copy.c:1488                                       
#7  0x0000000000512deb in CopyTo (cstate=0x802c4bc80) at copy.c:1402           
#8  0x0000000000512959 in DoCopyTo (cstate=0x802c4bc80) at copy.c:1252         
#9  0x0000000000512489 in DoCopy (stmt=0x801bfec28,                            
    queryString=0x801bfe030 "COPY public.tablename (ts, caid, casn, fn, data, textdata) TO stdout;") at copy.c:1148                                            
#10 0x0000000000633fa3 in ProcessUtility (parsetree=0x801bfec28,
    queryString=0x801bfe030 "COPY public.tablename (ts, caid, casn, fn, data, textdata) TO stdout;", params=0x0, isTopLevel=1 '\001', dest=0x801bfe850,
    completionTag=0x7fffffffe540 "") at utility.c:712
#11 0x000000000063267e in PortalRunUtility (portal=0x802c61030, utilityStmt=0x801bfec28,
    isTopLevel=1 '\001', dest=0x801bfe850, completionTag=0x7fffffffe540 "") at pquery.c:1173
---Type <return> to continue, or q <return> to quit---
#12 0x00000000006327e3 in PortalRunMulti (portal=0x802c61030, isTopLevel=1 '\001',
    dest=0x801bfe850, altdest=0x801bfe850, completionTag=0x7fffffffe540 "") at pquery.c:1266
#13 0x0000000000631e70 in PortalRun (portal=0x802c61030, count=9223372036854775807,
    isTopLevel=1 '\001', dest=0x801bfe850, altdest=0x801bfe850,
    completionTag=0x7fffffffe540 "") at pquery.c:813
#14 0x000000000062c2ff in exec_simple_query (
    query_string=0x801bfe030 "COPY public.tablename (ts, caid, casn, fn, data, textdata) TO stdout;") at postgres.c:1004
#15 0x000000000063025a in PostgresMain (argc=4, argv=0x801b3a780,
    username=0x801b3a750 "pgsql") at postgres.c:3631
#16 0x00000000005f739f in BackendRun (port=0x801b0a000) at postmaster.c:3207
#17 0x00000000005f691a in BackendStartup (port=0x801b0a000) at postmaster.c:2830
#18 0x00000000005f4526 in ServerLoop () at postmaster.c:1274
#19 0x00000000005f3f5c in PostmasterMain (argc=4, argv=0x7fffffffeb58) at postmaster.c:1029
#20 0x000000000058f34a in main (argc=4, argv=0x7fffffffeb58) at main.c:188

Guy Helmer <ghelmer@palisadesys.com> writes:
> Tom Lane wrote:
>> Normally I'd say "data corruption", but it is odd if you got the
>> identical message from two different machines.  Can you reproduce
>> it with a debugger attached?  If so, a backtrace from the call of
>> errfinish might be useful.

> Yes, here is the backtrace.

Well, that looks just about like you'd expect for a bytea column.

Hmm ... you mentioned 500MB total in the textdata column.  Is it
possible that that's nearly all in one entry?  It's conceivable
that the text representation of the entry is simply too large.
(The next question of course would be how you got the entry in there,
but maybe it was submitted in binary protocol, or built by
concatenation.)

            regards, tom lane

Tom Lane wrote:

Guy Helmer <ghelmer@palisadesys.com> writes: 

Tom Lane wrote:   

Normally I'd say "data corruption", but it is odd if you got the
identical message from two different machines.  Can you reproduce
it with a debugger attached?  If so, a backtrace from the call of
errfinish might be useful.     

Yes, here is the backtrace.   

Well, that looks just about like you'd expect for a bytea column.

Hmm ... you mentioned 500MB total in the textdata column.  Is it
possible that that's nearly all in one entry?  It's conceivable
that the text representation of the entry is simply too large.
(The next question of course would be how you got the entry in there,
but maybe it was submitted in binary protocol, or built by
concatenation.)
		regards, tom lane 

On the system where I captured the backtrace, there are several 400MB-long entries in the textdata column.  I inserted these entries by doing an "INSERT (..., textdata) VALUES (..., $1)", mmap'ed the data from a file into memory, and executed the command using PQexecParams().

Is there a quantifiable limit to the size of values I insert into a bytea column?  I haven't found a limit documented anywhere...

Thanks,
Guy

Guy Helmer <ghelmer@palisadesys.com> writes:
> On the system where I captured the backtrace, there are several
> 400MB-long entries in the textdata column.  I inserted these entries by
> doing an "INSERT (..., textdata) VALUES (..., $1)", mmap'ed the data
> from a file into memory, and executed the command using PQexecParams().

OK, then it's just that the values are too long to print :-(

> Is there a quantifiable limit to the size of values I insert into a
> bytea column?  I haven't found a limit documented anywhere...

The hard limit is that the text representation has to fit into 1GB.
The text form can range from 1 to 5 characters per byte, so the worst
case would be that you hit this at about 200MB.

FWIW, there is already code in place for 8.5 that establishes a
hex-based representation with a 2:1 multiplier, so that you could expect
to go up to 500MB with future releases.  On the whole, though, you might
want to think about storing these values as large objects or external
files.

            regards, tom lane