Lines Matching refs:power
948 ** after reboot following a crash or power loss, the only bytes in a
2044 ** of 8. Some allocators round up to a larger multiple or to a power of 2.
2197 ** (a power of two between 512 and 65536) plus some extra bytes for each
9070 ** be allocated by the cache. ^szPage will always a power of two. ^The
9706 ** start a callback but which do not need the full power (and corresponding
14686 ** Determine if the argument is a power of two
27008 ** 1. All memory allocation sizes are rounded up to a power of 2.
27020 ** allocation size (after rounding all sizes up to a power of 2.) Let M
27042 ** size of the array is a power of 2.
27044 ** The size of this object must be a power of two. That fact is
27203 int iFullSz; /* Size of allocation rounded up to power of 2 */
27221 /* Round nByte up to the next valid power of two */
27225 ** block. If not, then split a block of the next larger power of
27366 ** memsys5Round(). Hence nBytes is always a non-negative power
27397 ** All allocations must be a power of two and must be expressed by a
27451 /* The size of a Mem5Link object must be a power of two. Verify that
33969 ** Compute 10 to the E-th power. Examples: E==1 results in 10.
39038 ** (2) An application crash or power loss can leave stale lock files
40441 ** or power failure will likely corrupt the database file.
40583 ** If we do not do this and we encounter a power failure, the directory
41105 ** words, after a power-loss event, parts of the file that were never
41345 assert( ((pgsz-1)&pgsz)==0 ); /* Page size must be a power of 2 */
41410 ** And if the *-shm file has been corrupted by a power failure or
52243 ** Should be a power of 2, and ideally, evenly divide into BITVEC_USIZE.
52763 ** syncing the rollback journal, which might cause corruption on a power
55907 ** This could conceivably cause corruption following a power failure on
56237 ** checking information. If the power fails while the journal is being
56239 ** file after power is restored. If an attempt is then made
56988 ** power failure in this case anyway.
57135 ** are within range. To be 'in range', both values need to be a power
57560 ** Otherwise the journal might resurrect following a power loss and
57694 ** If journal corruption occurs due to a power failure, the most likely
57827 ** thought. If a power failure occurs while the journal is being written,
57882 ** journal. Otherwise, a power loss might leave modified data in the
58280 ** value of nRec from the size of the journal file. But if a power
58289 ** no-sync option for the journal. A power failure could lead to corruption
58291 ** deleted when the power is restored) we don't care.
59075 ** of the database to damage due to OS crashes or power failures by
59085 ** that an inopertune power failure could leave the journal
59246 ** * the new page size (value of *pPageSize) is valid (a power
59540 ** that if a power-failure occurs during the rollback, the process that
59702 ** file may be played back into the database. If a power failure occurs
59811 ** previous connection's transaction), and a crash or power-failure
61640 ** a sector need to be journalled in case of a power loss in the middle of
61666 ** an integer power of 2. It sets variable pg1 to the identifier
63678 ** The szPage value can be any power of 2 between 512 and 32768, inclusive.
63958 #define HASHTABLE_NPAGE 4096 /* Must be power of 2 */
63960 #define HASHTABLE_NSLOT (HASHTABLE_NPAGE*2) /* Must be a power of 2 */
64633 /* If the database page size is not a power of two, or is greater than
65382 ** in the WAL and can be recovered following a power-loss or hard reset.
67615 ** "no such page". The page size can be any power of 2 between 512 and 65536.
71567 ** how well the database resists damage due to OS crashes and power
71592 ** The page size must be a power of 2 between 512 and 65536. If the page
71596 ** Page sizes are constrained to be a power of two so that the region
71902 /* EVIDENCE-OF: R-25008-21688 The size of a page is a power of two
72762 ** and populated with enough information so that if a power loss occurs
80261 ** the database file in any way, knowing that if a power failure
80569 /* True if X is a power of two. 0 is considered a power of two here.
99978 ** actually N elements in size, where N is the smallest power of 2 greater
100030 ** being merged (rounded up to the next power of 2).
100033 int nTree; /* Used size of aTree/aReadr (power of 2) */
100950 ** nReader is automatically rounded up to the next power of two.
100954 int N = 2; /* Smallest power of two >= nReader */
102990 ** smaller journals that are not critical for power-loss recovery.
107596 ** is a power of two. That is true for sqlite3ExprListAppend() returns
126033 ** whose index is a power of two: 1, 2, 4, 8, 16, 32, ... */
126861 ** exp(X) - Compute e to the X-th power
126883 ** power(X,Y) - Compute X to the Y-th power
127071 MFUNCTION(power, 2, pow, math2Func ),
149611 ** And a power loss in between deleting the original and renaming the
187806 ** "new_size" must be a power of 2. The hash table might fail
208235 ** the RBU update database are not atomic. So if the power fails at the
208694 ** If a power failure or application crash occurs during an update, following
212556 ** after this step, then rbu_step() again, then a power failure occurs,
217526 ** allocate up to this limit - instead of up to the largest power of
230492 ** nSeg is always a power of two greater than or equal to the number of
245301 sqlite3_log(SQLITE_ERROR, "codec: cipher_page_size not a power of 2 and between 512 and 65536 inclusive(%d).", size);