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