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