Daniel Rall wrote:
> On Tue, 23 Jan 2007, Hyrum K. Wright wrote:
...
>> My main concern is that we have a unbounded number of copy_pair_t
>> structures which get allocated in setup_copy() from its main pool. They
>> are created before we do existence checking, and would not be destroyed
>> in the case of an error. We also have other resources, such as ra
>> sessions, which don't get cleaned up properly. Those could impact the
>> server, as well as the client.
>>
>> In the typical error case, we don't worry about it, because we assume
>> the pool is going to get destroyed quickly anyway. That assumption
>> isn't valid in this case.
>
> Sounds like some additional pool juggling wouldn't be out of line,
> then. Either that, or restructure the code to handle the
> copy_as_child parameter deeper in the call stack.
Or just use a subpool for calls to setup_copy(). We could then
duplicate *commit_info_t before returning from the client API, and
safely destroy the subpool. This approach seems a lot less invasive to me.
-Hyrum
Received on Wed Jan 24 17:49:36 2007