Lines Matching full:need

18 reservations bounds. At this point we need to explain how relogging works. With
138 For single shot operations that need to reach stable storage immediately, or
163 enough to take into account the amount of metadata that the change might need to
192 rolls are likely for the common modifications that need to be made.
207 modifications we make only need to reserve log space once.
241 and need to write into the log. The reserve head is used to prevent new
267 we need to be able to *overcommit* the log reservation space. As has already
421 need to ensure application level data integrity is maintained.
450 changes to the log buffers, we need to ensure that the object we are formatting
479 Hence we avoid the need to lock items when we need to flush outstanding
509 The memory buffer and associated vector need to be passed as a single object,
510 but still need to be associated with the parent object so if the object is
517 are in the item, so we'd need a new encapsulation method for regions in the log
523 Hence we need to keep the vector, but by attaching the memory buffer to it and
535 them to be used without limitations, we need to be able to track and accumulate
573 We need to write these items in the order that they exist in the CIL, and they
574 need to be written as an atomic transaction. The need for all the objects to be
581 To fulfill this requirement, we need to write the entire CIL in a single log
598 might need to tune the recovery transaction object hash size.
602 code to write the changes into the log. To do this efficiently, we need to
628 to store the list of log vectors that need to be written into the transaction.
629 Hence log vectors need to be able to be chained together to allow them to be
694 the log vector chaining. If we track by the log vectors, then we only need to
713 To do this, transactions need to record the LSN of the commit record of the
724 increasing sequence number assigned to it without the need for an external
735 To ensure that we can do this, we need to track all the checkpoint contexts
743 It should be noted that the synchronous forces may need to be extended with
750 are also committed to disk before the one we need to wait for. Therefore we
751 need to check that all the prior contexts in the committing list are also
752 complete before waiting on the one we need to complete. We do this
753 synchronisation in the log force code so that we don't need to wait anywhere
758 is, we need to flush the CIL and potentially wait for it to complete. This is a
774 still need to reserve the space in the log for the checkpoint.
808 reservation needs to be made before the checkpoint is started, and we need to
809 be able to reserve the space without sleeping.  For a 8MB checkpoint, we need a
813 permanent reservation on the space, but we still need to make sure we refresh
818 The problem with this is that it can lead to deadlocks as we may need to commit
836 are added to the CIL and avoid the need for reserving and regranting log space
841 log. Hence as part of the reservation growing, we need to also check the size
843 the maximum threshold, we need to push the CIL to the log. This is effectively