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@hub.org secondary: scrappy@{freebsd|postgresql}.org
