On Tue, 23 Jan 2007, Hyrum K. Wright wrote:
> Daniel Rall wrote:
> > I also didn't notice us setting *commit_info_p anywhere when there are
> > no commitables (WC -> WC and REPOS -> WC ops, where no commits occur).
> > Do we need something like this patch?
> The API docs don't make any guarantees as to what becomes *commit_info_p
> when it is not used. When combined with improved documentation, this
> patch seems reasonable.
Okay, done in r23197.
> 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.
Received on Wed Jan 24 00:06:12 2007
- application/pgp-signature attachment: stored