Re: [HACKERS] Break down the problem...

Further to this...

If I follow this back, the problem appears to be in nbtsort.c, around line
584, where:

#3 0x22c23 in _bt_spoolinit (index=0x1a5a10, ntapes=7, isunique=0)
at nbtsort.c:584
584 btspool->bts_itape[i] =
(gdb) list
579 elog(ERROR, "_bt_spoolinit: out of memory");
580 }
581
582 for (i = 0; i < ntapes; ++i)
583 {
584 btspool->bts_itape[i] =
585 _bt_tapecreate(mktemp(strcpy(fname,
TAPETEMP)));
586 btspool->bts_otape[i] =
587 _bt_tapecreate(mktemp(strcpy(fname,
TAPETEMP)));
5

Basically, _bt_tapecreate() is being passed a temp name...this doesn't
make sense, does it?

Why are doing:

btspool->bts_itape[i] =
_bt_tapecreate(mktemp(strcpy(fname, TAPETEMP)));

Instead of just doing:

btspool->bts_itape[i] =
_bt_tapecreate(mktemp(TAPETEMP));

Is there a reason why we are copying TAPETEMP into fname first, and then
freeing it right after?

Regardless of the above, GDB shows:

(gdb) print fname
$1 = 0x1a4ed0 "pg_btsortX21438"

For the above context, which is expected...

But, if I go back one, to inside teh _bt_tapecreate() function, GDB shows:

#2 0x22920 in _bt_tapecreate (fname=0x0) at nbtsort.c:433
433 tape->bttb_fd = FileNameOpenFile(fname, O_RDWR | O_CREAT |
O_TRUNC, 0600);
(gdb) print fname
$2 = 0x0

Am I missing something with GDB, or did fname lose its value here
somewhere?

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org