Re: [HACKERS] memory problems in copying large table to STDOUT

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(at)osprey(dot)astro(dot)umass(dot)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
>
>************
>