RE: IDL management in idl.c

["Jonghyuk Choi" <jongchoi@us.ibm.com>]

>The announcement for ITS#1651 just now showed up, after this email, so
sorry
>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
filterindex
>patch.

Yes, we should check the availability/reliability of alloca() upon
configure.

>I don't see any need to change the current behavior of the bdb_idl
functions
>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
>two
>BDB_IDL_DB_SIZE arrays on the stack.With the current sizes, this is never
a
>problem. If the objective here is to increase the sizes, that's another
>story.
>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
be small.
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
the
>deleted item is either the lo or hi bound of the range? Hm, I guess
there's
>a bug here as well in the BDB_IDL_MULTI case, since it always uses a
cursor
>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.