[Date Prev][Date Next]
RE: IDL management in idl.c
>The announcement for ITS#1651 just now showed up, after this email, so
>for any late responses.
I don't know why ITS showed up just now.... sorry.
>alloca() is nice in general, but as I recall it's only reliable in GCC. If
>we can rely on its behavior, then it would be good to use in the
Yes, we should check the availability/reliability of alloca() upon
>I don't see any need to change the current behavior of the bdb_idl
>since they don't nest recursively. At most, bdb_idl_insert_key() calls
>bdb_idl_fetch_key() once to retrieve an existing key. So there are at most
>BDB_IDL_DB_SIZE arrays on the stack.With the current sizes, this is never
>problem. If the objective here is to increase the sizes, that's another
>Otherwise, the code in filterindex.c is the only place that presents the
>danger of stack blowout, which is why I focused on that.
Yes, there's not many recursions, but the current BDB_IDL_DB_SIZE seems to
I started looking at this, because of the txn_prepare/txn_commit failure
reported by Pierangelo early this month.
How about the dynamic management of multiple small-to-moderate-sized IDLs ?
If we delare IDL as 'ID** ids;' and allocate ids[k] by BDB_IDL_DB_SIZE
chunk upon an overflow,
then the size of IDLs can be very large upon demand.
>On a sidenote, I see that in bdb_idl_delete_key we always assume that
>deleting from a range is a no-op. Perhaps we should shrink the range if
>deleted item is either the lo or hi bound of the range? Hm, I guess
>a bug here as well in the BDB_IDL_MULTI case, since it always uses a
>to delete the given item. If you delete the lo or hi bound of a range, the
>range item will be "broken". Amazing the things you see after being away
>from the code for a while.