Lines Matching refs:items

116 actually relatively easy to do - all the changes to logged items are already
192 Hence we avoid the need to lock items when we need to flush outstanding
240 Hence we avoid needing a new on-disk format to handle items that have been
253 The log item is already used to track the log items that have been written to
254 the log but not yet written to disk. Such log items are considered "active"
264 such, we cannot reuse the AIL list pointers for tracking committed items, nor
269 Similar to the AIL, tracking of committed items is done through a new list
270 called the Committed Item List (CIL).  The list tracks log items that have been
274 and done to make it easy for debugging - the last items in the list are the
283 all the items in the CIL must be written into the log via the log buffers.
284 We need to write these items in the order that they exist in the CIL, and they
306 formatted log items and a commit record at the tail. From a recovery
308 bigger with a lot more items in it. The worst case effect of this is that we
312 items are stored as log vectors, we can use the existing log buffer writing
324 all the current items from the CIL during a checkpoint operation, we move all
329 committed items and effectively allow new transactions to be issued while we
338 into the new CIL, then checkpoint transaction commit code cannot use log items
341 detached from the log items. That is, when the CIL is flushed the memory
396 run transaction committed processing for the log items (i.e. insert into AIL
402 it. The fact that we walk the log items (in the CIL) just to chain the log
482 amount of log space required as we add items to the commit item list, but we
535 items in the CIL and using this to dynamically calculate the amount of log
544 Hence we can grow the checkpoint transaction reservation dynamically as items
558 If the transaction subsystem goes idle while we still have items in the CIL,
569 Currently log items are pinned during transaction commit while the items are
570 still locked. This happens just after the items are formatted, though it could
571 be done any time before the items are unlocked. The result of this mechanism is
572 that items get pinned once for every transaction that is committed to the log
573 buffers. Hence items that are relogged in the log buffers will have a pin count
585 log items becomes unbalanced if we retain the "pin on transaction commit, unpin
605 lock to guarantee that we pin the items correctly.
620 	2. Adding items to the CIL and updating item space accounting
631 relatively long period of time - the pinning of log items needs to be done
642 items, it will get held for a significant time and so spin contention is a
653 The second serialisation point is on the transaction commit side where items
757 		Remove items from CIL
783 committing of the log items to the log itself and the completion processing.