I probably introduced this bug trying to clean up a buffer leak in
nbtree code.

***************
*** 499,507 ****
ItemPointerSetInvalid(iptr);
}

- pfree (scan->opaque);
if ( so->keyData != (ScanKey) NULL )
pfree (so->keyData);
_bt_dropscan(scan);
}

--- 496,504 ----
ItemPointerSetInvalid(iptr);
}

if ( so->keyData != (ScanKey) NULL )
pfree (so->keyData);
+ pfree (so);
_bt_dropscan(scan);
}
------------------------------

Search Discussions

  • Vadim B. Mikheev at Mar 24, 1997 at 3:57 am

    Chris Dunlop wrote:

    (The first difference is just a little cleanup - the actual fix is the
    second difference, starting at line 499.)

    *** src/backend/access/nbtree/nbtree.c.orig Wed Mar 19 10:00:21 1997
    --- src/backend/access/nbtree/nbtree.c Mon Mar 24 05:25:55 1997
    ***************
    *** 425,434 ****
    so->numberOfKeys = scan->numberOfKeys;
    so->numberOfFirstKeys = 0;
    so->qual_ok = 1; /* may be changed by _bt_orderkeys */
    ! if (scan->numberOfKeys > 0) {
    ! memmove(scan->keyData,
    ! scankey,
    ! scan->numberOfKeys * sizeof(ScanKeyData));
    memmove(so->keyData,
    scankey,
    so->numberOfKeys * sizeof(ScanKeyData));
    --- 425,431 ----
    A days ago, while fixing btree for joins, I moved actual keys
    used in scan to so (scanopaque), because of _bt_orderkeys
    may re-order keys and even exclude some of them - so scan->keyData
    holds untouched keys. I'm not sure, but we may be can re-order
    scan->keyData itself (btbeginscan()->RelationGetIndexScan()
    pallocs scan->keyData and so scankeys in IndexScanState will
    not be broken) and use them in scan... So, real cleanup would
    to remove keyData from scanopaque, but, for the moment,
    let's keep this little overcoding.

    I'll apply your bug fix today, in 1-2 hours.

    Vadim

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMar 23, '97 at 7:58p
activeMar 24, '97 at 3:57a
posts2
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Vadim B. Mikheev: 1 post Bruce Momjian: 1 post

People

Translate

site design / logo © 2021 Grokbase