Re: [HACKERS] memory problems in copying large table to STDOUT - Mailing list pgsql-hackers

Hi Tom,

I got the backtrace with ""Memory exhausted in
AllocSetAlloc()" this time.  The process has a virtual image
size of 103840 which is consistent with SHMMAX + the text
and stack size (in case this fact is of any use) . . .

Again, I've saved the process in case checking any symbols
would be helpful.

--Martin

----------------------------------------------------------------------

(gdb) bt
#0  0x4012eb77 in pause ()
#1  0x81160e9 in elog (lev=1,    fmt=0x814f05d "Memory exhausted in AllocSetAlloc()") at elog.c:81
#2  0x811949e in AllocSetAlloc (set=0x8232fb0, size=875628846) at aset.c:273
#3  0x8119a13 in PortalHeapMemoryAlloc (this=0x81efbd8, size=875628846)   at portalmem.c:264
#4  0x8119732 in MemoryContextAlloc (context=0x81efbd8, size=875628846)   at mcxt.c:230
#5  0x810ebf1 in textout (vlena=0x4106182c) at varlena.c:190
#6  0x808508c in CopyTo (rel=0x822af08, binary=0 '\000', oids=0 '\000',    fp=0x0, delim=0x813c829 "\t") at copy.c:421
#7  0x8084ce4 in DoCopy (relname=0x8235068 "psc", binary=0 '\000',    oids=0 '\000', from=0 '\000', pipe=1 '\001',
filename=0x0,   delim=0x813c829 "\t") at copy.c:323
 
#8  0x80ea8c6 in ProcessUtility (parsetree=0x8235080, dest=Remote)   at utility.c:227
#9  0x80e8a36 in pg_exec_query_dest (   query_string=0xbfffb274 "copy psc to STDOUT;", dest=Remote, aclOverride=0)   at
postgres.c:727
#10 0x80e8944 in pg_exec_query (query_string=0xbfffb274 "copy psc to STDOUT;")   at postgres.c:656
#11 0x80e9b88 in PostgresMain (argc=11, argv=0xbffff7ec, real_argc=12,    real_argv=0xbffffd04) at postgres.c:1647
#12 0x80d1adc in DoBackend (port=0x81ef748) at postmaster.c:1628
#13 0x80d1613 in BackendStartup (port=0x81ef748) at postmaster.c:1373
#14 0x80d0ca6 in ServerLoop () at postmaster.c:823
#15 0x80d080c in PostmasterMain (argc=12, argv=0xbffffd04) at postmaster.c:616
#16 0x80a4597 in main (argc=12, argv=0xbffffd04) at main.c:93
(gdb) 

Tom Lane wrote on Sun, 10 Oct 1999 11:59:53 EDT
>Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:
>> I am attaching the backtrace.  This one simultaneously generated
>> this kernel message from the md driver:
>
>> raid0_map bug: hash->zone0==NULL for block 1132810879
>> Bad md_map in ll_rw_block
>
>> Definitely a problem but no longer sure if it's the same one . . .
>> sigh.  
>
>Looks like it is not the same.  As you can see, the error message that
>elog is about to report is "cannot read <block#> of <file>", which isn't
>too surprising given the kernel notice:
>
>> #1  0x81160e9 in elog (lev=-1, fmt=0x8146a4b "cannot read block %d of %s")
>>     at elog.c:81
>
>If this read failure is reproducible then you will need to get that
>taken care of before we can make any progress on the original problem.
>But it might be a transient failure --- why don't you just start the
>copy over again to see?
>
>            regards, tom lane
>
>************
>