Tom Lane wrote on Sat, 09 Oct 1999 11:54:34 EDT
>Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:
>> I've been struggling to copy a large table (200 million
>> records, 60GB) to tape using:
>>    psql -qc "copy psc to STDOUT;" Winter99 | dd of=/dev/st0 bs=32k
>> After processing about 10 million records (this varies), I
>> get:
>>   FATAL 1:  Memory exhausted in AllocSetAlloc()
>
>Hmm.  What is the exact declaration of the table?
>
>The only explanation I can think of offhand is that the output
>conversion function for one of the column types is leaking memory...
>copy.c itself looks to be pretty careful not to.
>

The table def is:

CREATE TABLE psc (
	hemis		text,
	date		date,
	scan		int2,
	id		int4,
	ra		float4,
	dec		float4,
	glon		float4,
	glat		float4,
	err_maj		float4,
	err_min		float4,
	err_ang		int2,
	xscan		float4,
	cnf_flag	text,
	j_m		float4,
	h_m		float4,
	k_m		float4,
	j_msig		float4,
	h_msig		float4,
	k_msig		float4,
	j_m_psf		float4,
	h_m_psf		float4,
	k_m_psf		float4,
	j_psfchi	float4,
	h_psfchi	float4,
	k_psfchi	float4,
	j_skyval	float4,
	h_skyval	float4,
	k_skyval	float4,
	j_blend		int2,
	h_blend		int2,
	k_blend		int2,
	j_m_stdap	float4,
	h_m_stdap	float4,
	k_m_stdap	float4,
	j_msig_stdap	float4,
	h_msig_stdap	float4,
	k_msig_stdap	float4,
	j_prob_pers	float4,
	h_prob_pers	float4,
	k_prob_pers	float4,
	j_prg_flg	text,
	h_prg_flg	text,
	k_prg_flg	text,
	j_mrg_flg	text,
	h_mrg_flg	text,
	k_mrg_flg	text,
	j_pix_flg	text,
	h_pix_flg	text,
	k_pix_flg	text,
	j_cal		float4,
	h_cal		float4,
	k_cal		float4,
	gal_contam	int2,
	id_opt		text,
	dist_opt	float4,
	b_m_opt		float4,
	r_m_opt		float4,
	j_h		float4,
	h_k		float4,
	j_k		float4,
	dup_src		int2,
	use_src		int2,
	ext_key_1	int4
);

Thanks for taking a look,

--Martin

===========================================================================

Martin Weinberg                      Phone: (413) 545-3821
Dept. of Physics and Astronomy       FAX:   (413) 545-2117/0648
530 Graduate Research Tower	     weinberg@astro.umass.edu
University of Massachusetts	     http://www.astro.umass.edu/~weinberg/
Amherst, MA  01003-4525

Sat, 09 Oct 1999 12:02:27 -0300
Martin Weinberg <weinberg@osprey.astro.umass.edu>
Re: [HACKERS] memory problems in copying large table to STDOUT 
Folks,

I've been struggling to copy a large table (200 million
records, 60GB) to tape using:

   psql -qc "copy psc to STDOUT;" Winter99 | dd of=/dev/st0 bs=32k

After processing about 10 million records (this varies), I
get:

  FATAL 1:  Memory exhausted in AllocSetAlloc()

(The tape drive is a DLT 7000, and the tape is not filled at
this point).

There is no evidence that the backend has really exhausted
avail memory (I have 256MB but 1GB swap and the postgres
user and database user both have unlimited memory usage).

This is 6.5.1 on Linux 2.2.11 (w/Debian 2.1) on a dual
450Mhz Xeon box with a 128GB software Raid0 array.  I've set
SHMEM to 128MB am using "-B 12288 -S 8192".  I've been
trying to figure this out for a few weeks but can't seem to
get this table copied to tape.  Can one of the developers
offer a suggestion?

BTW, this is a large astronomical database which will
eventually grow to about 500 million records.  Besides this
tape problem, pgsql is now working nicely for our
application.

I've been following the mysql thread.  You folks may want
to add "works with databases over 2GB" to your plus column.

With thoughtful indexing, one can retrieve queries of
<100000 records in 1 to 15 minutes which competes nicely
with our main data server, a bunch of Sun Enterprise 5000
and 6000s running Informix.  Of course, many people using
this large system simultaneously, but our goal for this
project is to recommend an alternative hardware/software
solution to the astronomical community for <$10K.

--M

===========================================================================

Martin Weinberg                      Phone: (413) 545-3821
Dept. of Physics and Astronomy       FAX:   (413) 545-2117/0648
530 Graduate Research Tower	     weinberg@astro.umass.edu
University of Massachusetts	     http://www.astro.umass.edu/~weinberg/
Amherst, MA  01003-4525

Sat, 9 Oct 1999 11:04:14 -0400
Martin Weinberg <weinberg@osprey.astro.umass.edu>
memory problems in copying large table to STDOUT
Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:
> I've been struggling to copy a large table (200 million
> records, 60GB) to tape using:
>    psql -qc "copy psc to STDOUT;" Winter99 | dd of=/dev/st0 bs=32k
> After processing about 10 million records (this varies), I
> get:
>   FATAL 1:  Memory exhausted in AllocSetAlloc()

Hmm.  What is the exact declaration of the table?

The only explanation I can think of offhand is that the output
conversion function for one of the column types is leaking memory...
copy.c itself looks to be pretty careful not to.

			regards, tom lane

Sat, 09 Oct 1999 11:54:34 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] memory problems in copying large table to STDOUT 
Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:
> Tom Lane wrote on Sat, 09 Oct 1999 11:54:34 EDT
>>> FATAL 1:  Memory exhausted in AllocSetAlloc()
>> 
>> Hmm.  What is the exact declaration of the table?
>> 
>> The only explanation I can think of offhand is that the output
>> conversion function for one of the column types is leaking memory...
>> copy.c itself looks to be pretty careful not to.

> The table def is:

> CREATE TABLE psc (
> 	hemis		text,
> 	date		date,
> 	scan		int2,
> 	id		int4,
> 	ra		float4,
>       [ lots more fields of these same types ]

Hmm, nothing unusual there.  I made up a dummy table containing these
column types, filled it with 16 meg of junk data, and copied in and
out without observing any process memory usage growth at all, under
both current sources and 6.5.2.  I also used gdb to set a breakpoint
at AllocSetAlloc, and checked that the inner loop of the copy wasn't
allocating anything it didn't free.  So there's no obvious memory
leakage bug here.  (It'd be pretty surprising if there was, really,
for such commonly used data types.)

I'm now thinking that there must be either a problem specific to your
platform, or some heretofore unnoticed problem with copying from a
multi-segment (ie, multi-gigabyte) table.  I don't have enough disk
space to check the latter theory here...

Can you prepare a debugger backtrace showing what the backend is doing
when it gets the error?  If you're not familiar with gdb, it'd go
something like this:

1. Build & install postgres with debugging symbols enabled
   ("make CUSTOM_COPT=-g all"). 
2. Start gdb on the postgres executable, eg
   "gdb /usr/local/pgsql/bin/postgres".
3. Fire up the copy-out operation as usual.  (I assume this takes long
   enough that you have plenty of time for the next two steps ;-))
4. Use ps or top to find out the process number of the backend handling
   the session.
5. Attach to that process number in gdb:
	(gdb)	attach NNNN
6. Set a breakpoint at elog, and let the backend continue running:
	(gdb)	break elog
	(gdb)	continue
7. When the breakpoint is hit, get a backtrace:
	Breakpoint 1, elog ...
	(gdb)	bt
   After copying & pasting the resulting printout, you can "quit" to
   get out of gdb.

			regards, tom lane

Sat, 09 Oct 1999 14:42:56 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] memory problems in copying large table to STDOUT 
Tom,

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.  

I inserted a pause() in the beginning of elog.c so that I
could attach remotely; I'm keeping the sleeping processing
around in case there's anything else you would like me to
check.

Guess, I'm (foolishly?) pushing the envelope here with a 100GB 
database on software raid.

Thanks!!!

--Martin

P.S. After the fact, I realized that my source is Oliver Elphick's
Debian 6.5.1 source package rather than a pure vanilla source.  
Hope this is not a problem . . .

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

(gdb) bt
#0  0x4012eb77 in pause ()
#1  0x81160e9 in elog (lev=-1, fmt=0x8146a4b "cannot read block %d of %s")
    at elog.c:81
#2  0x80e76ef in smgrread (which=0, reln=0x822af60, blocknum=2638753, 
    buffer=0x44a85040 "h") at smgr.c:235
#3  0x80dd7a2 in ReadBufferWithBufferLock (reln=0x822af60, blockNum=2638753, 
    bufferLockHeld=0) at bufmgr.c:302
#4  0x80dd682 in ReadBuffer (reln=0x822af60, blockNum=2638753) at bufmgr.c:180
#5  0x80ddf1d in ReleaseAndReadBuffer (buffer=9175, relation=0x822af60, 
    blockNum=2638753) at bufmgr.c:954
#6  0x806ad13 in heapgettup (relation=0x822af60, tuple=0x8235374, dir=1, 
    buffer=0x8235398, snapshot=0x8232af0, nkeys=0, key=0x0) at heapam.c:469
#7  0x806b6bf in heap_getnext (scandesc=0x8235360, backw=0) at heapam.c:912
#8  0x8084eb3 in CopyTo (rel=0x822af60, binary=0 '\000', oids=0 '\000', 
    fp=0x0, delim=0x813c829 "\t") at copy.c:405
#9  0x8084ce4 in DoCopy (relname=0x82350c0 "psc", binary=0 '\000', 
    oids=0 '\000', from=0 '\000', pipe=1 '\001', filename=0x0, 
    delim=0x813c829 "\t") at copy.c:323
#10 0x80ea8c6 in ProcessUtility (parsetree=0x82350d8, dest=Remote)
    at utility.c:227
#11 0x80e8a36 in pg_exec_query_dest (
    query_string=0xbfffaef4 "copy psc to STDOUT;", dest=Remote, aclOverride=0)
    at postgres.c:727
#12 0x80e8944 in pg_exec_query (query_string=0xbfffaef4 "copy psc to STDOUT;")
    at postgres.c:656
#13 0x80e9b88 in PostgresMain (argc=11, argv=0xbffff46c, real_argc=12, 
    real_argv=0xbffff984) at postgres.c:1647
#14 0x80d1adc in DoBackend (port=0x81ef748) at postmaster.c:1628
#15 0x80d1613 in BackendStartup (port=0x81ef748) at postmaster.c:1373
#16 0x80d0ca6 in ServerLoop () at postmaster.c:823
#17 0x80d080c in PostmasterMain (argc=12, argv=0xbffff984) at postmaster.c:616
#18 0x80a4597 in main (argc=12, argv=0xbffff984) at main.c:93


Tom Lane wrote on Sat, 09 Oct 1999 14:42:56 EDT
>Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:
>> Tom Lane wrote on Sat, 09 Oct 1999 11:54:34 EDT
>>>> FATAL 1:  Memory exhausted in AllocSetAlloc()
>>> 
>>> Hmm.  What is the exact declaration of the table?
>>> 
>>> The only explanation I can think of offhand is that the output
>>> conversion function for one of the column types is leaking memory...
>>> copy.c itself looks to be pretty careful not to.
>
>> The table def is:
>
>> CREATE TABLE psc (
>> 	hemis		text,
>> 	date		date,
>> 	scan		int2,
>> 	id		int4,
>> 	ra		float4,
>>       [ lots more fields of these same types ]
>
>Hmm, nothing unusual there.  I made up a dummy table containing these
>column types, filled it with 16 meg of junk data, and copied in and
>out without observing any process memory usage growth at all, under
>both current sources and 6.5.2.  I also used gdb to set a breakpoint
>at AllocSetAlloc, and checked that the inner loop of the copy wasn't
>allocating anything it didn't free.  So there's no obvious memory
>leakage bug here.  (It'd be pretty surprising if there was, really,
>for such commonly used data types.)
>
>I'm now thinking that there must be either a problem specific to your
>platform, or some heretofore unnoticed problem with copying from a
>multi-segment (ie, multi-gigabyte) table.  I don't have enough disk
>space to check the latter theory here...
>
>Can you prepare a debugger backtrace showing what the backend is doing
>when it gets the error?  If you're not familiar with gdb, it'd go
>something like this:
>
>1. Build & install postgres with debugging symbols enabled
>   ("make CUSTOM_COPT=-g all"). 
>2. Start gdb on the postgres executable, eg
>   "gdb /usr/local/pgsql/bin/postgres".
>3. Fire up the copy-out operation as usual.  (I assume this takes long
>   enough that you have plenty of time for the next two steps ;-))
>4. Use ps or top to find out the process number of the backend handling
>   the session.
>5. Attach to that process number in gdb:
>	(gdb)	attach NNNN
>6. Set a breakpoint at elog, and let the backend continue running:
>	(gdb)	break elog
>	(gdb)	continue
>7. When the breakpoint is hit, get a backtrace:
>	Breakpoint 1, elog ...
>	(gdb)	bt
>   After copying & pasting the resulting printout, you can "quit" to
>   get out of gdb.
>
>			regards, tom lane
>
>************
>

Sun, 10 Oct 1999 10:38:43 -0300
Martin Weinberg <weinberg@osprey.astro.umass.edu>
Re: [HACKERS] memory problems in copying large table to STDOUT 
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

Sun, 10 Oct 1999 11:59:53 -0400
Tom Lane <tgl@sss.pgh.pa.us>
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@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
>
>************
>

Sun, 10 Oct 1999 20:37:04 -0300
Martin Weinberg <weinberg@osprey.astro.umass.edu>
Re: [HACKERS] memory problems in copying large table to STDOUT 
Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:
> I got the backtrace with ""Memory exhausted in
> AllocSetAlloc()" this time.

> #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

OK, that shoots down the "memory leak" theory.  It sure looks like
what you've got is corrupt data: textout is reading a length word of
875628846 (plus or minus a couple bytes) from what is supposed to be
a text datum.    Obviously that's not right.  Next question is how
it got that way.

I think it's pretty likely that the original cause is the kernel disk
driver or disk hardware flakiness that we already have evidence for.
However, I hate passing the buck like that, so I'm willing to continue
digging if you are.

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

You should look at the source tuple location info in CopyTo ---
something like
	(gdb)	f 6		-- frame 6, ie, CopyTo
	(gdb)	p i		-- get column number
	(gdb)   p *tuple	-- print contents of HeapTupleData
	(gdb)   p *tuple->t_data  -- print contents of HeapTupleHeaderData
	
The last is mainly to find out the tuple's OID for possible future
reference.  What we want right now is the tuple location info,
tuple->t_self, which will give us a block number (bi_hi and bi_lo in
that struct are the high and low 16 bits of the block number).  Then,
if you can use dd and od to get a hex dump of that block from the
relation's data files, we can see what's really on disk there.
(Remember that the "blocks" are 8K each; also, if you get an offset
beyond 1 gig, then it's going to be in one of the continuation files
"psc.1", "psc.2", etc --- one gig apiece.)

It would also be useful to look at the contents of the disk block as
sitting in memory in the backend, to see if they are the same as what
you read using dd; I would not be too surprised to find they are not.
The t_data pointer should be pointing into a disk buffer in Postgres'
shared memory block, but offhand I'm not sure what's the easiest way to
discover the starting address of that buffer using gdb.  (Can any other
hackers lend a hand here?)

			regards, tom lane

Sun, 10 Oct 1999 21:33:00 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] memory problems in copying large table to STDOUT 
Hi Tom,

Tom Lane wrote on Sun, 10 Oct 1999 21:33:00 EDT
>
>I think it's pretty likely that the original cause is the kernel disk
>driver or disk hardware flakiness that we already have evidence for.
>However, I hate passing the buck like that, so I'm willing to continue
>digging if you are.

Honestly, I'm inclined to agree but I'd like to know for sure before
go buy a hardware raid controller (or give up trying to build a
database this large with Linux altogether).  The "coincidence" that's
haunting me here is that I used pgsql on a 12GB database of the same
sort with no trouble for about 6 months.  All of this started when I
tried to load 60GB.  And after loading the table, I index it and
exercise it and everything is fine.  Twice now, this problem has
arisen when I've tried to backup the table with a "copy".  The first
time, I wiped out the raid array, got the latest kernel with the
up-to-date raid patches and rebuilt (takes a while . . .).  Same thing
again.  Of course, this copy hits the disks pretty hard, so maybe it's
not so coincidental.  Anyway, ruling out a pgsql problem would be
progress.

>> Again, I've saved the process in case checking any symbols
>> would be helpful.
>
>You should look at the source tuple location info in CopyTo ---
>something like
>	(gdb)	f 6		-- frame 6, ie, CopyTo
>	(gdb)	p i		-- get column number
>	(gdb)   p *tuple	-- print contents of HeapTupleData
>	(gdb)   p *tuple->t_data  -- print contents of HeapTupleHeaderData
>	
>The last is mainly to find out the tuple's OID for possible future
>reference.  What we want right now is the tuple location info,
>tuple->t_self, which will give us a block number (bi_hi and bi_lo in
>that struct are the high and low 16 bits of the block number).  Then,
>if you can use dd and od to get a hex dump of that block from the
>relation's data files, we can see what's really on disk there.
>(Remember that the "blocks" are 8K each; also, if you get an offset
>beyond 1 gig, then it's going to be in one of the continuation files
>"psc.1", "psc.2", etc --- one gig apiece.)
>

Ok done.  Here's what I find:

(gdb) p i
$1 = 48
(gdb) p *tuple
$2 = {t_len = 352, t_self = {ip_blkid = {bi_hi = 24, bi_lo = 26279}, 
    ip_posid = 19}, t_data = 0x41061710}
(gdb) p *tuple->t_data
$3 = {t_oid = 37497689, t_cmin = 0, t_cmax = 0, t_xmin = 17943, t_xmax
= 0, 
  t_ctid = {ip_blkid = {bi_hi = 24, bi_lo = 26279}, ip_posid = 19}, 
  t_natts = 63, t_infomask = 2307, t_hoff = 40 '(', t_bits = "<FF><FF><FF><FF>"}

Now, check me to make sure I've followed you correctly:

Since 1GB of blocks is 0x20000, this data in the 13th GB.
The offset into the 13th is 26279.

So I did:

dd if=psc.12 skip=26279 count=1 bs=8k | od -t x > ~/dump.hex

I'm not sure what I'm looking for in dump.hex.  The first hand full
of lines are:

0000000 01840064 20002000 02c09ea0 02809d60
0000020 02c09c00 02989ab4 02c09954 02989808
0000040 028096c8 02809588 02c09428 02c092c8
0000060 02c09168 02c09008 02c08ea8 02988d5c
0000100 02c08bfc 02c08a9c 0280895c 02588830
0000120 02c086d0 02c08570 02588444 02c082e4
0000140 02c08184 00000000 00000000 00000000
0000160 00000000 00000000 00000000 00000000
*
0000600 00000000 023c2b5d 00000000 00000000
0000620 00004617 00000000 66a70018 003f0017
0000640 ff280903 ffffffff 000fffff 00000005
0000660 00000073 fffffd95 000000ac 00003d2b
.
.
.

--Martin


===========================================================================

Martin Weinberg                      Phone: (413) 545-3821
Dept. of Physics and Astronomy       FAX:   (413) 545-2117/0648
530 Graduate Research Tower	     weinberg@astro.umass.edu
University of Massachusetts	     http://www.astro.umass.edu/~weinberg/
Amherst, MA  01003-4525

Mon, 11 Oct 1999 00:17:21 -0300
Martin Weinberg <weinberg@osprey.astro.umass.edu>
Re: [HACKERS] memory problems in copying large table to STDOUT 
Tom Lane wrote on Mon, 11 Oct 1999 10:59:25 EDT
>
>Looks good.  For fun you might try "select * from psc where oid = 37497689"
>and see if it succeeds or not on a "retail" retrieval of the problem tuple.

Yes . . . the backend dies with status 11.  Could this be that I
can't do this until "release" the other process since it seems to
have gobbled all the shared memory?

>Could you send the whole dump?  I can figure this stuff out by hand but
>I'm not sure I can explain it to someone else.  (The relevant data
>structure declarations are in various files in src/include/storage/ and
>src/include/access/ if you want to look for yourself.)

Here it is:

0000000 01840064 20002000 02c09ea0 02809d60
0000020 02c09c00 02989ab4 02c09954 02989808
0000040 028096c8 02809588 02c09428 02c092c8
0000060 02c09168 02c09008 02c08ea8 02988d5c
0000100 02c08bfc 02c08a9c 0280895c 02588830
0000120 02c086d0 02c08570 02588444 02c082e4
0000140 02c08184 00000000 00000000 00000000
0000160 00000000 00000000 00000000 00000000
*
0000600 00000000 023c2b5d 00000000 00000000
0000620 00004617 00000000 66a70018 003f0017
0000640 ff280903 ffffffff 000fffff 00000005
0000660 00000073 fffffd95 000000ac 00003d2b
0000700 4375bc7b c142851c 4024fe3b 41cb436f
0000720 3df5c28f 3df5c28f 0000002d c0e851ec
0000740 0000000a 31313131 00003131 416ec49c
0000760 41676873 41672b02 3cfdf3b6 3d1fbe77
0001000 3da7ef9e 416ec49c 41676873 41672b02
0001020 3fc8f5c3 3f866666 3f91eb85 438015c3
0001040 445407ae 44b6f429 00010001 00000001
0001060 416ecccd 41661893 416476c9 3d810625
0001100 3de147ae 3e48b439 00000000 00000000
0001120 00000000 00000007 00303030 00000007
0001140 00303030 00000007 00303030 0000000a
0001160 30303030 00003030 0000000a 30303030
0001200 00003030 0000000a 30303030 00003030
0001220 00000008 36363030 00000008 36363030
0001240 00000008 36333030 bd2c0831 bd1ba5e3
0001260 bced9168 00000000 00000011 35373055
0001300 36393030 35373237 00000032 3ee147ae
0001320 41873333 417e6666 3eeb851f 3c75c28f
0001340 3ef33333 023c2b5c 00000000 00000000
0001360 00004617 00000000 66a70018 003f0016
0001400 ff280903 ffffffff 000fffff 00000005
0001420 00000073 fffffd95 000000ac 00003d2c
0001440 4375b28f c14283ee 4023590c 41cb80be
0001460 3e851eb8 3e4ccccd 0000000b 43011eb8
0001500 0000000a 31313131 00003131 418226e9
0001520 417d4396 41764dd3 3db43958 3df9db23
0001540 3e3851ec 418226e9 417d4396 41764dd3
0001560 3fb47ae1 3f4ccccd 3f6147ae 437fbae1
0001600 445437ae 44b6e000 00010001 00000001
0001620 418047ae 4181126f 4178ed91 3e49ba5e
0001640 3e8ccccd 3e418937 00000000 00000000
0001660 00000000 00000007 00303030 00000007
0001700 00303030 00000007 00303030 0000000a
0001720 30303030 00003030 0000000a 30303030
0001740 00003030 0000000a 30303030 00003030
0001760 00000008 36323030 00000008 36303030
0002000 00000008 35303130 bd2c0831 bd1ba5e3
0002020 bced9168 00000000 00000011 35373055
0002040 36393030 37343037 00000034 3d8f5c29
0002060 41980000 418d999a 3ee147ae 3edeb852
0002100 3f600000 023c2b5b 00000000 00000000
0002120 00004617 00000000 66a70018 003f0015
0002140 ff280903 edbefbff 000e1fff 00000005
0002160 00000073 fffffd95 000000ac 00003d2e
0002200 4375af05 c1427b74 4022dec2 41cb9919
0002220 3e570a3d 3e428f5c 0000005d 4331c51f
0002240 0000000a 30313031 00003030 41871062
0002260 4181645a 4180f5c3 3e126e98 3e1db22d
0002300 41871062 4181645a 4185624e 3f7851ec
0002320 3fa8f5c3 437fc7ae 445463d7 40d4cccd
0002340 00010001 4188851f 417d1eb8 3e9a1cac
0002360 3e656042 00000000 00000000 00000000
0002400 00000007 00303030 00000007 00303030
0002420 00000007 006c6966 0000000a 30303030
0002440 00003030 0000000a 30303030 00003030
0002460 0000000a 30303030 00003030 00000008
0002500 36303030 00000008 36303030 00000005
0002520 00000030 bd2c0831 bd1ba5e3 bced9168
0002540 00000000 3f358106 3d5d2f1b 3f4353f8
0002560 023c2b5a 00000000 00000000 00004617
0002600 00000000 66a70018 003f0014 ff280903
0002620 ffffffff 000fffff 00000005 00000073
0002640 fffffd95 000000ac 00003d2f 4375c250
0002660 c14279bb 40261fbc 41cb231d 3df5c28f
0002700 3df5c28f 0000005a c2aee148 0000000a
0002720 31313131 00003131 415c6666 4154c083
0002740 41531aa0 3cc49ba6 3ccccccd 3d178d50
0002760 415c6666 4154c083 41531aa0 3f666666
0003000 3f933333 3f7851ec 43802000 4454299a
0003020 44b6bbd7 00010001 00000001 415c7efa
0003040 4154bc6a 41527ae1 3cbc6a7f 3d8d4fdf
0003060 3d7df3b6 00000000 00000000 00000000
0003100 00000007 00303030 00000007 00303030
0003120 00000007 00303030 0000000a 30303030
0003140 00003030 0000000a 30303030 00003030
0003160 0000000a 30303030 00003030 00000008
0003200 36363030 00000008 36363030 00000008
0003220 36363030 bd2c0831 bd1ba5e3 bced9168
0003240 00000000 00000011 35373055 36393030
0003260 30313437 00000037 3f0a3d71 4180cccd
0003300 41700000 3ef4bc6a 3dd2f1aa 3f14bc6a
0003320 023c2b59 00000000 00000000 00004617
0003340 00000000 66a70018 003f0013 ff280903
0003360 ffffffff 000fffff 00000005 00000073
0003400 fffffd95 000000ac 00003d31 4375c8ba
0003420 c1427477 402744d4 41cafd50 3e800000
0003440 3e428f5c 0000004f c32fa3d7 0000000a
0003460 31313131 00003131 41810c4a 417b4bc7
0003500 41769fbe 3d9db22d 3dd70a3d 3e395810
0003520 41810c4a 417b4bc7 41769fbe 3f666666
0003540 3f9c28f6 3f7851ec 437f8000 44541333
0003560 44b6e7ae 00010001 00000001 4180126f
0003600 41783958 41753f7d 3dc8b439 3e25e354
0003620 3e1ba5e3 00000000 00000000 00000000
0003640 00000007 00303030 00000007 00303030
0003660 00000007 00303030 0000000a 30303030
0003700 00003030 0000000a 30303030 00003030
0003720 0000000a 30303030 00003030 00000008
0003740 36313030 00000008 09310931 34310931
0003760 3237382e 2e343109 09393035 342e3431
0004000 00000000 00000011 35373055 36393030
0004020 35353537 00000035 3f4ccccd 4195999a
0004040 418c0000 3ed9999a 3e958106 3f378d50
0004060 023c2b58 00000000 00000000 00004617
0004100 00000000 66a70018 003f0012 ff280903
0004120 edbefbff 000e1fff 00000005 00000073
0004140 fffffd95 000000ac 00003d32 4375abb4
0004160 c1427133 40227432 41cbb0a2 3e570a3d
0004200 3e428f5c 000000a2 435f599a 0000000a
0004220 30313031 00003030 41860c4a 41820c4a
0004240 4174b852 3e116873 3e3851ec 41860c4a
0004260 41820c4a 4177ba5e 3f4f5c29 3fa00000
0004300 43800000 44544b85 40df0a3d 00010001
0004320 41861eb8 41818312 3e395810 3ebbe76d
0004340 00000000 00000000 00000000 00000007
0004360 00303030 00000007 00303030 00000007
0004400 006c6966 0000000a 30303030 00003030
0004420 0000000a 30303030 00003030 0000000a
0004440 30303030 00003030 00000008 36303030
0004460 00000008 36303030 00000005 00000030
0004500 bd2c0831 bd1ba5e3 bced9168 00000000
0004520 3f000000 3f760419 3fbb020c 023c2b57
0004540 00000000 00000000 00004617 00000000
0004560 66a70018 003f0011 ff280903 ffffffff
0004600 000e1fff 00000005 00000073 fffffd95
0004620 000000ac 00003d38 4375b2a2 c14260bd
0004640 4023d6b6 41cb8b2a 3df5c28f 3df5c28f
0004660 00000056 4300147b 0000000a 31313131
0004700 00003131 4177a5e3 416f53f8 4168dd2f
0004720 3d48b439 3d6d9168 3da9fbe7 4177a5e3
0004740 416f53f8 4168dd2f 3f7ae148 3f9851ec
0004760 3f70a3d7 437f547b 44543c29 44b6bd71
0005000 00010001 00000001 4178c49c 416f4fdf
0005020 41678d50 3d810625 3e2f1aa0 3dba5e35
0005040 00000000 00000000 00000000 00000007
0005060 00303030 00000007 00303030 00000007
0005100 00303030 0000000a 30303030 00003030
0005120 0000000a 30303030 00003030 0000000a
0005140 30303030 00003030 00000008 36363030
0005160 00000008 36333030 00000008 36303030
0005200 bd2c0831 bd1ba5e3 bced9168 00000000
0005220 3f051eb8 3eced917 3f6c8b44 023c2b56
0005240 00000000 00000000 00004617 00000000
0005260 66a70018 003f0010 ff280903 ffffffff
0005300 000fffff 00000005 00000073 fffffd95
0005320 000000ac 00003d3b 4375c079 c1425ae2
0005340 40263c43 41cb37f5 3df5c28f 3df5c28f
0005360 0000005a c278a3d7 0000000a 31313131
0005400 00003131 413e0c4a 4133eb85 4131e354
0005420 3cb43958 3cbc6a7f 3cd4fdf4 413e0c4a
0005440 4133eb85 4131e354 3f19999a 3f400000
0005460 3ee66666 4380ab85 445420a4 44b71614
0005500 00010001 00000001 413da9fc 41341062
0005520 41319db2 3c75c28f 3cf5c28f 3c9374bc
0005540 00000000 00000000 00000000 00000007
0005560 00303030 00000007 00303030 00000007
0005600 00303030 0000000a 30303030 00003030
0005620 0000000a 30303030 00003030 0000000a
0005640 30303030 00003030 00000008 35353130
0005660 00000008 36363030 00000008 35353130
0005700 bd2c0831 bd1ba5e3 bced9168 00000000
0005720 00000011 35373055 36393030 36363337
0005740 00000038 3f170a3d 41700000 41566666
0005760 3f220c4a 3e020c4a 3f428f5c 023c2b55
0006000 00000000 00000000 00004617 00000000
0006020 66a70018 003f000f ff280903 ffffffff
0006040 000fffff 00000005 00000073 fffffd95
0006060 000000ac 00003d3e 4375c67b c1425599
0006100 40275009 41cb14aa 3df5c28f 3df5c28f
0006120 0000002d c310c51f 0000000a 31313131
0006140 00003131 41732f1b 41660000 41636042
0006160 3d23d70a 3d178d50 3d89374c 41732f1b
0006200 41660000 41636042 3f8b851f 3f4a3d71
0006220 3f666666 437ff0a4 44541ccd 44b6f148
0006240 00010001 00000001 4172624e 41668b44
0006260 416147ae 3d03126f 3ddd2f1b 3ddf3b64
0006300 00000000 00000000 00000000 00000007
0006320 00303030 00000007 00303030 00000007
0006340 00303030 0000000a 30303030 00003030
0006360 0000000a 30303030 00003030 0000000a
0006400 30303030 00003030 00000008 36363030
0006420 00000008 35353130 00000008 36333030
0006440 bd2c0831 bd1ba5e3 bced9168 00000000
0006460 00000011 35373055 36393030 35303537
0006500 00000030 3faccccd 41973333 4189999a
0006520 3f52f1aa 3e27ef9e 3f7ced91 023c2b54
0006540 00000000 00000000 00004617 00000000
0006560 66a70018 003f000e ff280903 edbefbff
0006600 000fffff 00000005 00000073 fffffd95
0006620 000000ac 00003d45 4375bb2e c142481a
0006640 40259ad4 41cb5e49 3e19999a 3e19999a
0006660 0000002d 412947ae 0000000a 30313031
0006700 00003030 41826666 4179374c 4180872b
0006720 3db851ec 3db22d0e 41826666 4179374c
0006740 41850625 3f95c28f 3f9c28f6 437fb0a4
0006760 44540333 40d33333 00010001 418320c5
0007000 417ce560 3ea2d0e5 3ea8f5c3 00000000
0007020 00000000 00000000 00000007 00303030
0007040 00000007 00303030 00000007 006c6966
0007060 0000000a 30303030 00003030 0000000a
0007100 30303030 00003030 0000000a 30303030
0007120 00003030 00000008 36313030 00000008
0007140 36303030 00000005 00000030 bd2c0831
0007160 bd1ba5e3 bced9168 00000000 00000011
0007200 35373055 36393030 34343237 00000038
0007220 3f3851ec 419a6666 418b3333 3f395810
0007240 befae148 3e6f9db2 023c2b53 00000000
0007260 00000000 00004617 00000000 66a70018
0007300 003f000d ff280903 ffffffff 000fffff
0007320 00000005 00000073 fffffd95 000000ac
0007340 00003d48 4375c3cc c1424254 40272014
0007360 41cb2b20 3df5c28f 3df5c28f 0000002d
0007400 c2d7b852 0000000a 31313131 00003131
0007420 41681893 415f9db2 415d374c 3ced9168
0007440 3d03126f 3d3c6a7f 41681893 415f9db2
0007460 415d374c 3f733333 3fb33333 3f947ae1
0007500 437fae14 4453fb85 44b6f6b8 00010001
0007520 00000001 41674fdf 415f851f 415bced9
0007540 3c03126f 3d9374bc 3ddb22d1 00000000
0007560 00000000 00000000 00000007 00303030
0007600 00000007 00303030 00000007 00303030
0007620 0000000a 30303030 00003030 0000000a
0007640 30303030 00003030 0000000a 30303030
0007660 00003030 00000008 36363030 00000008
0007700 36363030 00000008 35343130 bd2c0831
0007720 bd1ba5e3 bced9168 00000000 00000011
0007740 35373055 36393030 35343437 00000031
0007760 3f6147ae 41873333 417ccccd 3f07ae14
0010000 3e19999a 3f2e147b 023c2b52 00000000
0010020 00000000 00004617 00000000 66a70018
0010040 003f000c ff280903 ffffffff 000fffff
0010060 00000005 00000073 fffffd95 000000ac
0010100 00003d4a 4375ad5e c14240f3 4023636f
0010120 41cbb55a 3df5c28f 3df5c28f 0000005a
0010140 43487ae1 0000000a 31313131 00003131
0010160 41609ba6 4158dd2f 4156353f 3cdd2f1b
0010200 3ce56042 3d23d70a 41609ba6 4158dd2f
0010220 4156353f 3f88f5c3 3f8b851f 3f828f5c
0010240 437fe666 44542852 44b6b5c3 00010001
0010260 00000001 4160a3d7 415778d5 4155c6a8
0010300 3cbc6a7f 3d872b02 3dc08312 00000000
0010320 00000000 00000000 00000007 00303030
0010340 00000007 00303030 00000007 00303030
0010360 0000000a 30303030 00003030 0000000a
0010400 30303030 00003030 0000000a 30303030
0010420 00003030 00000008 36363030 00000008
0010440 36363030 00000008 36363030 bd2c0831
0010460 bd1ba5e3 bced9168 00000000 00000011
0010500 35373055 36393030 38323936 00000036
0010520 3f2b851f 4185999a 41766666 3ef7ced9
0010540 3e29fbe7 3f266666 023c2b51 00000000
0010560 00000000 00004617 00000000 66a70018
0010600 003f000b ff280903 ffffffff 000fffff
0010620 00000005 00000073 fffffd95 000000ac
0010640 00003d4e 4375ab2d c142384d 40232374
0010660 41cbc580 3df5c28f 3df5c28f 0000005a
0010700 4366a148 0000000a 31313131 00003131
0010720 4173126f 416b0625 41666a7f 3d408312
0010740 3d5d2f1b 3da5e354 4173126f 416b0625
0010760 41666a7f 3fae147b 3faa3d71 3f95c28f
0011000 43800148 445438f6 44b6e3d7 00010001
0011020 00000001 41711eb8 4168f1aa 41659db2
0011040 3d591687 3df7ced9 3dba5e35 00000000
0011060 00000000 00000000 00000007 00303030
0011100 00000007 00303030 00000007 00303030
0011120 0000000a 30303030 00003030 0000000a
0011140 30303030 00003030 0000000a 30303030
0011160 00003030 00000008 36363030 00000008
0011200 36353030 00000008 36323030 bd2c0831
0011220 bd1ba5e3 bced9168 00000000 00000011
0011240 35373055 36393030 35373836 00000035
0011260 3f63d70a 418a6666 41833333 3f00c49c
0011300 3e9374bc 3f4a7efa 023c2b50 00000000
0011320 00000000 00004617 00000000 66a70018
0011340 003f000a ff280903 ffffffff 000fffff
0011360 00000005 00000073 fffffd95 000000ac
0011400 00003d4f 4375c0b4 c1423820 4026bf0a
0011420 41cb414c 3df5c28f 3df5c28f 0000005a
0011440 c282a3d7 0000000a 31313131 00003131
0011460 415ba1cb 415378d5 4153126f 3cc49ba6
0011500 3ccccccd 3d1374bc 415ba1cb 415378d5
0011520 4153126f 3f866666 3f570a3d 3f428f5c
0011540 43805c29 445417ae 44b6eeb8 00010001
0011560 00000001 415afdf4 4153f3b6 4154ac08
0011600 3cdd2f1b 3d5d2f1b 3d0b4396 00000000
0011620 00000000 00000000 00000007 00303030
0011640 00000007 00303030 00000007 00303030
0011660 0000000a 30303030 00003030 0000000a
0011700 30303030 00003030 0000000a 30303030
0011720 00003030 00000008 35353130 00000008
0011740 36363030 00000008 36363030 bd2c0831
0011760 bd1ba5e3 bced9168 00000000 00000011
0012000 35373055 36393030 33373337 00000034
0012020 3f88f5c3 417b3333 416ccccd 3f028f5c
0012040 3ccccccd 3f08f5c3 023c2b4f 00000000
0012060 00000000 00004617 00000000 66a70018
0012100 003f0009 ff280903 ffffffff 000fffff
0012120 00000005 00000073 fffffd95 000000ac
0012140 00003d51 4375bd58 c1423676 402634e3
0012160 41cb5674 3e051eb8 3e051eb8 0000002d
0012200 c1993333 0000000a 31313131 00003131
0012220 41780000 41706a7f 4172dd2f 3d48b439
0012240 3d50e560 3e16872b 41780000 41706a7f
0012260 4172dd2f 3f68f5c3 3fc28f5c 3f5c28f6
0012300 437ff0a4 44540a3d 44b70a8f 00010001
0012320 00000001 41770625 41779db2 416dbe77
0012340 3db43958 3ded9168 3df9db23 00000000
0012360 00000000 00000000 00000007 00303030
0012400 00000007 00303030 00000007 00303030
0012420 0000000a 30303030 00003030 0000000a
0012440 30303030 00003030 0000000a 30303030
0012460 00003030 00000008 36353030 00000008
0012500 36303030 00000008 36303030 bd2c0831
0012520 bd1ba5e3 bced9168 00000000 00000011
0012540 35373055 36393030 37393237 00000036
0012560 3f3851ec 418d999a 4184cccd 3ef2b021
0012600 be1cac08 3ea45a1d 023c2b4e 00000000
0012620 00000000 00004617 00000000 66a70018
0012640 003f0008 ff280903 ffffffff 000e1fff
0012660 00000005 00000073 fffffd95 000000ac
0012700 00003d52 4375c128 c1423492 4026dedb
0012720 41cb3f9a 3e8f5c29 3e851eb8 00000051
0012740 c28f23d7 0000000a 31313131 00003131
0012760 4182e76d 417a5604 41796042 3dba5e35
0013000 3dced917 3e560419 4182e76d 417a5604
0013020 41796042 3f9ae148 3f63d70a 3f428f5c
0013040 437fc51f 44542d71 44b6dae1 00010001
0013060 00000001 41839375 4178cccd 417a3d71
0013100 3edcac08 3df1a9fc 3e818937 00000000
0013120 00000000 00000000 00000007 00303030
0013140 00000007 00303030 00000007 00303030
0013160 0000000a 30303030 00003030 0000000a
0013200 30303030 00003030 0000000a 30303030
0013220 00003030 00000008 35313130 00000008
0013240 36303030 00000008 36303030 bd2c0831
0013260 bd1ba5e3 bced9168 00000000 3f378d50
0013300 3d75c28f 3f46e979 023c2b4d 00000000
0013320 00000000 00004617 00000000 66a70018
0013340 003f0007 ff280903 ffffffff 000e1fff
0013360 00000005 00000073 fffffd95 000000ac
0013400 00003d55 4375cc2c c1423065 4028c522
0013420 41cafd30 3df5c28f 3df5c28f 00000056
0013440 c35f028f 0000000a 31313131 00003131
0013460 417ec49c 41735c29 416e5a1d 3d9374bc
0013500 3d9374bc 3dced917 417ec49c 41735c29
0013520 416e5a1d 3f733333 3f75c28f 3f95c28f
0013540 43804148 4453feb8 44b6f0f6 00010001
0013560 00000001 417be354 4172c8b4 4170624e
0013600 3db43958 3e5c28f6 3e841893 00000000
0013620 00000000 00000000 00000007 00303030
0013640 00000007 00303030 00000007 00303030
0013660 0000000a 30303030 00003030 0000000a
0013700 30303030 00003030 0000000a 30303030
0013720 00003030 00000008 36333030 00000008
0013740 36323030 00000008 36303030 bd2c0831
0013760 bd1ba5e3 bced9168 00000000 3f36872b
0014000 3ea04189 3f8353f8 023c2b4c 00000000
0014020 00000000 00004617 00000000 66a70018
0014040 003f0006 ff280903 edbefbff 000fffff
0014060 00000005 00000073 fffffd95 000000ac
0014100 00003d56 4375c913 c1422f27 402844e1
0014120 41cb109b 3e3851ec 3e2e147b 00000078
0014140 c33470a4 0000000a 30313031 00003030
0014160 4183d4fe 418076c9 417cf9db 3dced917
0014200 3e116873 4183d4fe 418076c9 4182020c
0014220 3f99999a 3f7851ec 437f2e14 445410a4
0014240 40d9999a 00010001 4184c28f 4184c8b4
0014260 3e820c4a 3e947ae1 00000000 00000000
0014300 00000000 00000007 00303030 00000007
0014320 00303030 00000007 006c6966 0000000a
0014340 30303030 00003030 0000000a 30303030
0014360 00003030 0000000a 30303030 00003030
0014400 00000008 36313030 00000008 36303030
0014420 00000005 00000030 bd2c0831 bd1ba5e3
0014440 bced9168 00000000 00000011 35373055
0014460 36393030 33363537 00000036 3e8a3d71
0014500 4191999a 418f3333 3ed78d50 3e7ced91
0014520 3f2b020c 023c2b4b 00000000 00000000
0014540 00004617 00000000 66a70018 003f0005
0014560 ff280903 ffffffff 000fffff 00000005
0014600 00000073 fffffd95 000000ac 00003d58
0014620 4375b5f4 c1422d49 4025180d 41cb86b3
0014640 3df5c28f 3df5c28f 0000002d 42a4e666
0014660 0000000a 31313131 00003131 416c28f6
0014700 4164ac08 4164872b 3cf5c28f 3d1374bc
0014720 3d8d4fdf 416c28f6 4164ac08 4164872b
0014740 3f5eb852 3fa00000 3f47ae14 437fcf5c
0014760 44542f5c 44b6fa3d 00010001 00000001
0015000 416cf5c3 41643d71 416251ec 3cf5c28f
0015020 3d79db23 3df5c28f 00000000 00000000
0015040 00000000 00000007 00303030 00000007
0015060 00303030 00000007 00303030 0000000a
0015100 30303030 00003030 0000000a 30303030
0015120 00003030 0000000a 30303030 00003030
0015140 00000008 36363030 00000008 36363030
0015160 00000008 35333130 bd2c0831 bd1ba5e3
0015200 bced9168 00000000 00000011 35373055
0015220 36393030 34323137 00000034 3ef5c28f
0015240 41826666 417b3333 3eef9db2 3c1374bc
0015260 3ef43958 023c2b4a 00000000 00000000
0015300 00004617 00000000 66a70018 003f0004
0015320 ff280903 edbefbff 000fffff 00000005
0015340 00000073 fffffd95 000000ac 00003d5b
0015360 4375c246 c1422b6b 40272e84 41cb3b94
0015400 3e6147ae 3e4ccccd 00000049 c2add1ec
0015420 0000000a 30313031 00003030 418570a4
0015440 41812f1b 417e0419 3df7ced9 3e147ae1
0015460 418570a4 41812f1b 4182999a 3f51eb85
0015500 3f5eb852 438007ae 44540e14 40d051ec
0015520 00010001 41859ba6 41802d0e 3e25e354
0015540 3ec5a1cb 00000000 00000000 00000000
0015560 00000007 00303030 00000007 00303030
0015600 00000007 006c6966 0000000a 30303030
0015620 00003030 0000000a 30303030 00003030
0015640 0000000a 30303030 00003030 00000008
0015660 36303030 00000008 36303030 00000005
0015700 00000030 bd2c0831 bd1ba5e3 bced9168
0015720 00000000 00000011 35373055 36393030
0015740 39303437 00000039 3eb851ec 419b3333
0015760 41926666 3f083127 3e8b4396 3f4dd2f2
0016000 023c2b49 00000000 00000000 00004617
0016020 00000000 66a70018 003f0003 ff280903
0016040 ffffffff 000fffff 00000005 00000073
0016060 fffffd95 000000ac 00003d5f 4375c992
0016100 c14225e5 40287a31 41cb1070 3f028f5c
0016120 3f028f5c 0000005a c33b3852 0000000a
0016140 31313131 00003131 4187147b 41835c29
0016160 4180a3d7 3e189375 3e49ba5e 3e947ae1
0016200 4187147b 41835c29 4180a3d7 3f9ae148
0016220 3f451eb8 3f947ae1 437f75c3 44540ccd
0016240 44b6e948 00010001 00000001 418af5c3
0016260 418022d1 41a50000 3ea9fbe7 3e9a9fbe
0016300 410e353f 00000000 00000000 00000000
0016320 00000007 00303030 00000007 00303030
0016340 00000007 00303030 0000000a 30303030
0016360 00003030 0000000a 30303030 00003030
0016400 0000000a 30303030 00003030 00000008
0016420 36303030 00000008 36303030 00000008
0016440 36303030 bd2c0831 bd1ba5e3 bced9168
0016460 00000000 00000011 35373055 36393030
0016500 34373537 00000039 3f266666 4198cccd
0016520 418f3333 3eee147b 3eae147b 3f4e147b
0016540 023c2b48 00000000 00000000 00004617
0016560 00000000 66a70018 003f0002 ff280903
0016600 ffffffff 000e1fff 00000005 00000073
0016620 fffffd95 000000ac 00003d61 4375b6b0
0016640 c1422463 40255671 41cb84f3 3e6b851f
0016660 3e6147ae 00000047 4290bd71 0000000a
0016700 31313131 00003131 41847ae1 4179d2f2
0016720 4177a9fc 3de147ae 3dc28f5c 3e52f1aa
0016740 41847ae1 4179d2f2 4177a9fc 3f400000
0016760 3f91eb85 3f970a3d 437fbae1 44543852
0017000 44b6e052 00010001 00000001 41839ba6
0017020 41781062 41770625 3e52f1aa 3e818937
0017040 3ed6872b 00000000 00000000 00000000
0017060 00000007 00303030 00000007 00303030
0017100 00000007 00303030 0000000a 30303030
0017120 00003030 0000000a 30303030 00003030
0017140 0000000a 30303030 00003030 00000008
0017160 36303030 00000008 36313030 00000008
0017200 36303030 bd2c0831 bd1ba5e3 bced9168
0017220 00000000 3f722d0e 3e0a3d71 3f8a5e35
0017240 023c2b47 00000000 00000000 00004617
0017260 00000000 66a70018 003f0001 ff280903
0017300 ffffffff 000fffff 00000005 00000073
0017320 fffffd95 000000ac 00003d62 4375b331
0017340 c14221b7 4024c9cd 41cb9b43 3ea8f5c3
0017360 3e75c28f 0000004d 42f0e666 0000000a
0017400 31313131 00003131 4182b22d 417ced91
0017420 417bc28f 3dc8b439 3ddd2f1b 3e4ed917
0017440 4182b22d 417ced91 417bc28f 3f7ae148
0017460 3fa3d70a 3fa28f5c 437fc51f 44542c29
0017500 44b6fd71 00010001 00000001 41808937
0017520 4179f3b6 4173ef9e 3dcccccd 3e4ed917
0017540 3e872b02 00000000 00000000 00000000
0017560 00000007 00303030 00000007 00303030
0017600 00000007 00303030 0000000a 30303030
0017620 00003030 0000000a 30303030 00003030
0017640 0000000a 30303030 00003030 00000008
0017660 36303030 00000008 36313030 00000008
0017700 36303030 bd2c0831 bd1ba5e3 bced9168
0017720 00000000 00000011 35373055 36393030
0017740 32363037 00000035 3e8f5c29 41966666
0017760 418d999a 3f076c8b 3d958106 3f1a1cac
0020000

Mon, 11 Oct 1999 11:57:16 -0300
Martin Weinberg <weinberg@osprey.astro.umass.edu>
Re: [HACKERS] memory problems in copying large table to STDOUT 
Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:
> Ok done.  Here's what I find:

> (gdb) p i
> $1 = 48
> (gdb) p *tuple
> $2 = {t_len = 352, t_self = {ip_blkid = {bi_hi = 24, bi_lo = 26279}, 
>     ip_posid = 19}, t_data = 0x41061710}
> (gdb) p *tuple->t_data
> $3 = {t_oid = 37497689, t_cmin = 0, t_cmax = 0, t_xmin = 17943, t_xmax
> = 0, 
>   t_ctid = {ip_blkid = {bi_hi = 24, bi_lo = 26279}, ip_posid = 19}, 
>   t_natts = 63, t_infomask = 2307, t_hoff = 40 '(', t_bits = "<FF><FF><FF><FF>"}

Looks good.  For fun you might try "select * from psc where oid = 37497689"
and see if it succeeds or not on a "retail" retrieval of the problem tuple.

> Now, check me to make sure I've followed you correctly:
> Since 1GB of blocks is 0x20000, this data in the 13th GB.
> The offset into the 13th is 26279.
> So I did:
> dd if=psc.12 skip=26279 count=1 bs=8k | od -t x > ~/dump.hex

Looks right to me.

> I'm not sure what I'm looking for in dump.hex.

Could you send the whole dump?  I can figure this stuff out by hand but
I'm not sure I can explain it to someone else.  (The relevant data
structure declarations are in various files in src/include/storage/ and
src/include/access/ if you want to look for yourself.)

			regards, tom lane

Mon, 11 Oct 1999 10:59:25 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] memory problems in copying large table to STDOUT 